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PREFACE 


PURPOSE 


This manual contains information to describe maintenance options 
for an ORACLE Relational Database Management System 
(RDBMS). Though it docs not describe the installation of a system, 
it contains much information to help a DBA make the best decisions 
about system parameters and data storage, with the ultimate goals 
being good performance and a smoothly running system. 


AUDIENCE 


This manual is written for persons responsible for the operation of 
an ORACLE RDBMS. These persons, referred to as Database 
Administrators, or DBAs, are assumed to be responsible for assuring 
the smooth ongoing operation of an ORACLE RDBMS and for 
monitoring use in order to suggest ways to make ORACLE and its 
applications run better. 

DBAs are frequently involved in the initial and subsequent installa¬ 
tion of ORACLE systems; though this manual is not intended to be 
an installation manual, it does contain information relevant to 
options available during installation. If your primary interest is in¬ 
stallation, the Installation and User's Guide for your particular op¬ 
erating system is the primary source of information. 

Though the material in this manual is of interest primarily to DBAs, 
as opposed to general applications users, experienced ORACLE us¬ 
ers and advanced applications designers will also find the information 
helpful in designing or fine-tuning applications. 
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Readers of this guide are assumed to be familiar with ORACLE 
RDBMS concepts and have some experience using an ORACLE 
database. The first chapters are intended to give a brief overall look 
at ORACLE, but l^ter chapters rapidly go into much finer detail 
than a new user might easily comprehend. 


HOW THIS MANUAL IS ORGANIZED 


This manual contains information about how ORACLE RDBMS 
works in more detail than many casual or end users need to know, 
but of interest to persons desiring to control or improve perform¬ 
ance. For example, it describes how locking works, what the back¬ 
ground processes do, and what INIT.ORA parameters control. It 
contains information about items which you can change to improve 
how an ORACLE RDBMS works. For example, this manual may 
suggest INIT.ORA parameters you might want to adjust, and you 
may find ways to restructure queries to speed their execution. This 
manual also describes ORACLE utilities DBAs can use to monitor 
usage of an ORACLE RDBMS (such as SGI and ODS). 

Information in this manual is applicable to the ORACLE Relational 
Database Management System running on all operating systems, 
with very few exceptions. Exceptions are noted as they apply, with 
references to the manual providing more specific information; that 
manual is usually the Installation and User's Guide for xxx operating 
system, where xxx is the name of the hardware and operating system, 
as in DEC VAX/VMS or IBM MVS. In particular, users of single¬ 
process ORACLE, as on MS-DOS, can skip over sections of this 
manual which apply to a multi-user ORACLE system, and a note 
to that effect is found preceding such sections. 

This manual contains the following parts and chapters: 

Part I: Introduction to ORACLE RDBMS 

This part contains a basic general overview of the ORACLE product 
line. It introduces several common ORACLE terms, and outlines 
the responsibilities of the person called the Database Administrator 
(DBA). 

Chapter 1: What is ORACLE? 

This chapter introduces the ORACLE products forming the 
ORACLE product line, with brief descriptions of the products. It 
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also describes the SQL language, on which ORACLE is based. 

Basic ORACLE terms are defined. 

Chapter 2: The Role of the Database Administrator 

This chapter outlines responsibilities and concerns of the person who 
is responsible for maintaining an ORACLE database -- the Database 
Administrator or DBA for short. The two ORACLE DBA users, 
SYS and SYSTEM, are mentioned. 

Part II: Using the DBA Tools 

This part contains several chapters, each of which corresponds to an 
ORACLE program or utility of interest primarily to the DBA. 
Those utilities are 

IOR for starting and stopping an ORACLE system 

ODS for displaying runtime system statistics 

AM for recording database activity for recovery in the event of 
system failure. 

CRT for modifying display terminal characteristics and key 
mappings. 

Chapter 3: Using the IOR Program to Start and Stop ORACLE 

This chapter describes the different options of the IOR program 
which a DBA uses to start and stop ORACLE. Along with the 
discussion of IOR is a summary and description of the parameters 
in the INIT.ORA file which is read and used by the IOR program. 
A secondary utility, SGI, is also described; the DBA uses SGI to 
display the memory requirements of particular INIT.ORA files. 

Chapter 4: The ORACLE Display System Utility (ODS) 

This chapter describes the ODS program which is useful to monitor 
ongoing use of an ORACLE system. Different screens may be se¬ 
lected to indicate which users are active, which locks they are hold¬ 
ing, and how much activity has occurred in the database since the 
last warm start (IOR W). Of particular interest are the screens 
showing information about current locks, and the before image file. 

Chapter 5: After Image Journalling (AIJ) 

This chapter describes how to enable journalling, which is a backup 
program for recovery in the event of media or system failure, and 
how to recover using the AIJ files. Topics include requirements and 
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options of enabling AIJ and a discussion of what occurs during re¬ 
covery and possible errors. 

Chapter 6: Modifying Terminal Definitions (The CRT Utility) 

This chapter describes CRT, the utility to create and store terminal 
definitions, so as to be able to use full-screen ORACLE products on 
a variety of display devices. It describes the database tables used by 
CRT and how you can update these tables to adapt terminal defi¬ 
nitions for your installations's applications. 

Part III: ORACLE Database Structure 

This part describes in detail how data is stored in the database. The 
first chapter describes the data dictionary which is present in all da- 
• tabases, and is a central reference point for finding data. The next 

chapter describes data storage, beginning with the largest unit or 
biggest picture — the database -- and working down in detail to the 
finest unit or most detail - datatypes. 

Chapter 7: The ORACLE Data Dictionary 

This chapter describes the creation and purpose of the tables in the 
database referred to as the data dictionary. A listing of the tables' 
columns is found in Appendix B. 

Chapter 8: How is Data Stored in the Database? 

This chapter describes how data is stored in a database, starting from 
the most general picture to the most detailed -- from a description 
of the database, to what elements compose a database, down to the 
distinct types of data. Data conversion and temporary tables are also 
discussed. 

Part IV: Tuning ORACLE RDBMS for Performance 

This part contains information to help a DBA understand the inter¬ 
action of multiple users accessing the same data, and how ORACLE 
maintains consistency and integrity using locks to protect the data. 
Then it describes several means of optimizing performance; including 
the two most important means: indexing and clustering. After 
thorough discussions of index and cluster commands and usage, 
other optimization hints follow. 

Chapter 9: Consistency and Concurrency 

This chapter defines transactions and SQL, commands to control 
them. It also lists, defines, and illustrates the numerous locks which 
ORACLE uses to guarantee data integrity among multiple users. 
The three modes of locking are compared: exclusive mode, share 
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mode, and share update (or row-level) locking. Deadlock detection 
and resolution are also discussed. 

Chapter 10: Tuning a System for Performance 

This chapter describes the purpose and use of indexes and clusters, 
the two most important performance tools. It also covers context 
space and the performance implications of the wording of various 
SQL statements. 

Part V: ORACLE RDBMS Security Management 

This part discusses ORACLE features which allow the DBA to 
control access to the database and to track changes or attempted 
changes to the data. The AUDITing facility is also described, which 
allows users and DBAs to track database use at several different lev¬ 
els. 

Chapter 11: Enrolling and Dropping Users 

This chapter describes the SQL commands used to give users data¬ 
base privileges and take them away. Login options are discussed. 

Chapter 12: Using ORACLE Auditing 

This chapter describes ways a DBA can improve and monitor the 
security of a database system. Topics include enabling and using the 
auditing features. 

Appendix A lists the ORACLE reserved words. 

Appendix B lists the data dictionary tables, with column detail. 

Appendix C lists several ORACLE limits, such as the maximum 
number of characters in a CHAR datatype column or the maximum 
number of columns per table. 

Appendix D shows a summary of the INIT.ORA parameters, in¬ 
cluding a description, range, and default setting. 

This book also contains a glossary and an index. 


RELATED PUBLICATIONS 


Because this manual contains information applicable to ORACLE 
running under any operating system you will also want to refer often 


Preface / ix 


- 









to the guides containing information specific for your operating sys¬ 
tem. For example: 

• ORACLE for DEC VAX/ VMS Installation and Users Guide , 
ORACLE Part No. 1001 

• ORACLE for IBM VM/SP Installation and User's Guide , 
ORACLE Part No. 1003 

These guides are the two main sources of information for a DBA, 
or for more experienced ORACLE users. 

Other ORACLE publications are listed below. Release Notes are 
published most frequently, for several products, to announce 
changes, fixes, and new information about the products. Appendixes 
in the Release Notes may contain operating system specific infor¬ 
mation in addition to the install guides listed previously. 

Documentation parts for the ORACLE RDBMS are: 

• ORACLE RDBMS Release Notes , ORACLE Part No. 3001 

• ORACLE Overview and Introduction to SQL , ORACLE Part No 
3801 

• ORACLE Database Administrator's Guide , ORACLE Part No. 
3601 

• ORACLE Utilities User's Guide , ORACLE Part No. 3602 

• Error Messages and Codes , ORACLE Part No. 3605 
Other publications: 

• Database: A Primer , C.J. Date, Addison-Wcsley Publishing 
Company, 1983. 

• An Introduction to Database Systems, C.J. Date, Addison-Wesley 
Publishing Company, Volume I - 3rd edition, 1981, and Volume 
II - 1st edition, 1983. 

•An End-User's Guide to Data Base , James Martin, Prentice-IIall, 
1981. 

• Computer Data-Base Organization , James Martin, Prentice-IIall, 
1977. 

• Sorting and Searching , Donald E. Knuth, Addison-Wcsley, 1975. 
Pages 473-479 contain a discussion of B-tree indexing. 
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Conventions Used in this Manual 


The following conventions are observed in this manual: 

Ftte names 

File names appear in capital letters, as in I NIT.OR A. 
Portions of the file names which may vary appear in lower 
case, as in SGADEFx.ORA. 

Reserved words and keywords 

These words also appear in capital letters in examples and 
in text, to indicate that they are to be entered as is, and that 
they have reserved meanings within ORACLE. 

Key names 

Key names appear in capital letters, and are enclosed in 
square brackets as in [RETURN]. 


Command syntax: 


Commands 

This font is used to identify text which must be entered 
exactly as shown: 

SELECT * FROM 

Alternative items 

Alternative choices are separated by vertical bars (|). The 
set of alternative choices is enclosed by curly braces if one 
of the items is required, or by square brackets if the item is 
an optional alternative. (See below for the notation con¬ 
vention for required or optional items.) 

Required items 

Required items arc enclosed in curly braces { }. Users must 
choose one of the alternatives. 

Optional items 

Optional items are enclosed in square brackets. 

Repetitive items 

An ellipsis represents an arbitrary number of similar items. 
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YOUR COMMENTS ARE WELCOME 


Wc value and appreciate your comments as an ORACLE user and 
reader of the manuals. As we write, revise, and evaluate, your 
opinions are the most important input wc receive. At the back of 
this manual is a Reader's Comment Form which we encourage you 
to use to tell us both what you like and dislike about this (or other) 
ORACLE manuals. If the form is gone, or you would like to con¬ 
tact us, please use the following address, or call us at (415) 598-8000. 

Technical Publications Manager 
Oracle Corporation 
20 Davis Drive 
Belmont, California 94002 
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PART I: INTRODUCTION TO ORACLE RDBMS 


This part contains a basic general overview of the ORACLE product line. 
It introduces several common ORACLE terms, and outlines the responsi¬ 
bilities of the person called the Database Administrator (DBA). 


Part I: Introduction to ORACLE RDBMS / 1 
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CHAPTER 1. WHAT IS ORACLE? 


This chapter introduces the ORACLE products forming the ORACLE 
product line, with brief descriptions of the products. It also describes the 
SQL language, on which ORACLE is based. Basic ORACLE terms arc 
defined. 


THE ORACLE PRODUCT NAMING SCHEME 


With the release of Version 5 of the ORACLE RDBMS, several new 
ORACLE products are introduced. The ORACLE products are named 
using a scheme which indicates both the type and level of the product. A 
set of prefixes indicates the level, as follows: 

Easy Indicates full-screen products which guide users through their 
work offering them choices, via menus and detailed online help 
and information. Intended for new and infrequent users of the 
ORACLE RDBMS, or persons unfamiliar with computers. 

SQL Indicates products which arc interactive or command driven. 

Therefore assumes more comfort and expertise with the SQL 
language and ORACLE products. Intended for users with fair 
experience with ORACLE, SQL, and the data. 

Pro Indicates the programming interface to an ORACLE RDBMS. 

Pro interfaces require programming expertise, as well as experi¬ 
ence with SQL and ORACLE. These interfaces arc intended for 
programmers. 
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the oracle product line 


. hls sect !?£ th< = various products which may together be referred 

to as an ORACLE Database Management System. Many users wiJJ not 
require nor use all ORACLE products; however, users can take advantage 
ol the different products to accomplish various tasks in various ways. 


The SQL Language: Basis of All Utilities 


At the heart of ORACLE RDBMS is the SQL data language, pronounced 
sequel - an English-like data language. SQL is simple enough to allow 
beginning users to access data easily within a very brief time, yet it is 
powerful enough to offer programmers all the capability and flexibility they 


SQLwm developed and defined by IBM Research, and has been proposed 
by the American National Standards Institute (ANSI) as the basis for a 
standard language for relational database management systems. 

The SQL language statements arc often divided into four classifications: 

Queries Statements which retrieve existing data, in any combination, ex¬ 
pression, or order. Queries always begin with the SQL reserved 
word SELECT, followed by the data desired, and the tables or 
views containing the source data, as in: 


SELECT ENAME, MGR 
FROM EMP; 


Queries do not change the data; they only retrieve data. 

DML Data Manipulation language statements are used to change the 
data in three basic ways: 


• INSERT new rows of data into a table 

• UPDATE column values in existing rows 

• DELETE rows from tables 


DDL 


Data Definition Language statements are used to create database 
objects and to drop them when they're no longer needed DDL, 
statements include CREATE TABLE, CREATE VIEW CRE¬ 
ATE INDEX, CREATE SYNONYM, ALTER TABLE, and" 
corresponding DROP statements. 
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DCL Data Control language statements are used to give and take away 
privileges to access the database (such as GRANT CONNECI, 
RESOURCE, DBA) and see database data (such as GRANT 
SELECT and REVOKE DELETE). DCL statements allow one 
user to let other users of his choice see, change, and use data in 
his table, and even to pass their privileges on to other users 
(GRAN T SELECT ... WITH GRAN T). 


DCL statements are often grouped with DDL statements. Data 
control statements also include COMMI1, ROLLBACK, and 
LOCK TABLE, which control how and when data manipulation 
transactions occur, and the AUDI 1 statements. 


As you become more familiar with the ORACLE RDBMS you 11 see that 
DML, DDL, and query statements all have different implications on the 
database. Thus, this book may make occasional references to these classi¬ 
fications (DML, DDL, etc.) on the assumption that you understand which 
SQL statements fall in which category. 


The ORACLE RDBMS 


The ORACLE RDBMS is the central ORACLE product. It includes the 
kernel database manager and several features intended to assist users and 
DBAs in the maintenance, monitoring, and use of data. Following are the 
utilities included in the ORACLE RDBMS product (utilities noted for 
DBAs are documented in this manual): 

IOR DBA utility to start, stop, and initialize an ORACLE system. 

SGI DBA utility to describe the shared memory area used by 

ORACLE. 

ODS DBA utility (the ORACLE Display System) to monitor user and 
ORACLE processes. 

AIJ DBA utility (After Image Journalling) to log changes made to 
data, to allow for recovery in event of disk failure. 

CRT DBA utility to adjust screen display characteristics for full-screen 
products (like SQL*Forms) or to modify keypad function as¬ 
signments. 

Export/Import User utility to move ORACLE data to and from files, 
which can then be used for arcliiving data or moving data be¬ 
tween operating systems or ORACLE databases. 
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ODL User utility (ORACLE Data Loader) used to load data from O/S 
standard files. 


"Easy" ORACLE Products 


Easy* ORACLE products offer a variety of functions to beginning 

ORACLE users. Not all Easy" products arc available on every operating 
system. h 

• Easy*SQL 

Easy*SQL ORACLE is an MS-DOS version of Easy+SQL which contains 
the RDBMS and Easy ♦SQL only. 


"SQL" ORACLE Products 


The SQL* products are the main products in the ORACLE product line 

and oner many sophisticated means of accessing the data. Not all "SQL" 

products arc available on every operating system. 

SQL*Plus An interactive command-driven interface to ORACLE, useful 
for ad hoc queries and report writing. 

SQL forms A full-screen forms interface which allows users to create, 
modify, and use full-screen forms. 

SQL*Calc A spreadsheet interface fully integrated with ORACLE data. 

SQL*Mcnu A product for constructing a menu interface to any software 
piogram. It allows you to provide a means of executing many 
different programs and operating system commands under the 
same umbrella. 

SQL*Graph A product allowing graphic portrayal of database information. 

SQL*Rcport A product to merge and format text with ORACLE data. 

SQL*Net A product to access databases on computers other than where 
the database resides. 

SQ IT Calc ORACLE is an MS-DOS version of Easy+SQL which contains 

the RDBMS and SQL + Calc only. 
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"Pro" ORACLE Products 


The Pro* ORACLE products are programming interface products which 
allow programmers to develop applications in high level languages using 
ORACLE data. Programmers can use precompilers to imbed SQL state¬ 
ments in programs, or alternatively, a predefined set of subroutine calls, 
which use lower level calls to access data in the database. Several languages 
are supported: 

• Pro*C 

• Pro*COBOL 

• Pro+FORTRAN 

• Pro* PL/1 

• Pro* Pascal 

• Pro* Ada 

Not all operating system versions of ORACLE support all high level lan¬ 
guages; for details, see the Installation and User's Guide for your operating 
system. 

THE ORACLE VERSION NUMBERING SCHEME 


As ORACLE products are always undergoing development and change, 
several versions of the products are in use at any one time. To fully identify 
which version of any product your site is running, three numbers are re- 
quired: the version number, the maintenance release number, and the re¬ 
vision level. 


Version Number 


The version number, such as Version 5, is the most general identifier New 
versions are released when significant new functionality has been added to 
a product. 


Maintenance Release 


The maintenance release number signifies different releases of the general 
version, starting with 0, as in Version 4.0 or Version 5.0. The maintenance 
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Revision Level 


level increases by 1 when bug fixes or new features to existing programs are 


I he revision level identifies a specific level of the object code. This number 
is used primarily by Oracle Corporation to fully identify an ORACLE 
system; generally speaking, any installation will normally only receive one 
maintenance release. Only rarely will a site receive two tapes of one 
maintenance level, and in those cases, the revision level numbers arc not 
necessarily subsequent. 


As Oracle Corporation introduces new products and enhances existing 
ones, the version numbers of the individual products are independent of 
each other. Thus, you might have a V5.1.12 RDBMS system working with 
SQL Forms V2.0.3, SQL+Plus VI.0.9, and Pro + FORTRAN VI 1 2 
(these numbers are used only for illustration). 


AN INTRODUCTION TO ORACLE TERMS AND CONCEPTS 


This section briefly defines terms commonly used when discussing an 
ORACLE RDBMS. Cross references are given for additional information 
which appears in this manual. 


Basic Terms 


Release media 


Database Filc(s) 


Before image file 


I he tape (or other media, such as a cassette or diskette) which is distributed 
by Oracle Corporation and contains the object code and other files for the 
ORACLE RDBMS or for other Oracle Corporation products. In¬ 
structions for reading and loading the distribution media arc found in the 
Installation and User s Guides for each operating system. 

Fhese files (also called DB files) contain all the user data tables and data 
dictionary tables stored or generated by an ORACLE RDBMS. There is 
always at least one DB file. For more information on the database file, 
refer to the description of the INIT.ORA parameter DATABASE and to 
“The Database File” on page 97. 

This file (also called the BI file) contains images of data before changes arc 
made to it. It is used to guarantee that transactions are not made perma¬ 
nent until they are complete, consistent, and committed by the user; it is 
also used for rollback recovery in the event of hardware or system failure. 
The BI file also supports concurrent access to the data by multiple users. 
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After image file(s) 


Database administrator 


IOR program 


INIT.ORA tile 


SGA 


There is only one BI file per system. For more information on the before 
image file, refer to the description of the INI I .ORA parameter 
BEFORE IMAGE and to “The Before Image File” on page 134. 

These files (also called A1J files) are used to record transactions which have 
been committed, to use for rollforward recovery in the event of media fail¬ 
ure. For more information on the after image file, refer to the description 
of the INIT.ORA parameter AFTER_IMAGE and to “Chapter 5. After 
Image Journalling (AIJ)” on page 59. 

(DBA) The person responsible for maintaining the smooth operation of an 

ORACLE RDBMS; see "Chapter 2. The Role of the Database Adminis¬ 
trator (DBA)” on page 13. 

The program used by the DBA to start an ORACLE system (make avail¬ 
able for use) or stop a system (make unavailable, or turn off). IOR is also 
used to "initialize" the system (start it the first time). For more information 
on the IOR program, turn to “IOR Command and Parameters” on page 
19. 

This file contains several system parameters which arc read and used when 
starting a database system with the IOR program. Ihese parameters can 
be adjusted to affect how the RDBMS runs or to change certain limits. 
For example, each time ORACLE is started, the INIT.ORA file is read to 
find the names of the DB and BI files, and to see how many processes can 
log into ORACLE concurrently. For more information on INI 1 ORA 
refer to “The INIT.ORA Parameter File” on page 24. 

The System Global Area (SGA) is a shared storage area in main or virtual 
memory. It is allocated by the IOR program and is the center of data ac¬ 
tivity while ORACLE is running. The size of the SGA varies depending 
on the parameter settings in the INIT.ORA file. For example, the SGA 
contains the following: 

• data buffers 

• lock lists 

• column caches 

• table caches 

• user caches 


For more information on the SGA refer to the Installation and User s 
Guide for your operating system, and “The SGI Utility” on page 39. 
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Kernel 


Detached processes 


Shared code systems 


Shared partition system 


Multi-user systems 


Single-user systems 


Data dictionary 


Hus part of the ORACLE RDBMS performs SQL operations requested 
by users. It performs reads and writes to the DB and BI files, maintains 
data in the SGA, and coordinates the activities of multiple concurrent us¬ 
ers. 


If an ORACLE system is meant to be used by more than one user, it is 
installed as a multi-user system. Most systems are multi-user. To handle 
concurrent access of the database data, the ORACLE RDBMS requires 
additional "users", which are called various terms by different operating 
Kms (for example, detached processes in VMS or virtual machines for 
IBM VM operating systems). In this guide they are referred to as detached 
or background processes. The processes, named below, are described in 
more detail after this list of basic terms. 

ARH Read from the database file for users scanning tables 

BIW Write to before image file 

BWR Write to database and journal files 

CLN Clean up after failed processes 

The meaning of this term also varies by operating system, but generally 
speaking, when ORACLE is installed as a shared system, all ORACLE 
users and systems share the same physical object code. 

An ORACLE installation configuration where a single database (partition) 
and before unage file may be shared by multiple and independent 
ORACLE "systems" (sets of detached processes). An ORACLE cluster 
running on VAXclusters is a shared partition system. 

A multi-user system is a system which is designed to be accessed by several 
users concurrently. Because users may need to access the same tables or 
rows at the same time, ORACLE coordinates the actions of multiple users 
using 'locking". 

A database need not be accessed by multiple users and there are many 
reasons that one person only would require his own system. The 
ORACLE RDBMS can be invoked either single- or multi-user; if invoked 
in single-user mode, the operation of the RDBMS is somewhat simplified 
as the multi-user coordination is not necessary. However, this will not 
necessarily achieve performance gains. Whether a system is single-user or 
multi-user is set by the INIT.ORA parameter SINGLE USER. 

The Data Dictionary is a set of tables and views created and kept up-to- 
date by the ORACLE RDBMS. It contains administrative information 
about users, tables and other objects, and privileges, and is central to the 
operation of ORACLE. It is discussed in detail in “Chapter 7. The 
ORACLE Data Dictionary” on page 91. 
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THE FOUR BACKGROUND PROCESSES 


Asynchronous Read Ahead (ARH) 


ARH copies blocks from the database file into the SGA on behalf of any 
query doing a full table scan, to reduce the time to complete the query. 
Ideally, ARH has read a block into the SGA before a program needs to 
access the block. The INIT.ORA parameters affecting AR11 are 
READREQUESTS, READ BLKS_TOT, and READ_BLKS_RF,Q; 
however, it is recommended that you not alter them (see 1 he INIT.ORA 
Parameter File” on page 24). ARII reads blocks in parallel with the exe- 
cution of the program wanting to process the data retrieved. 


Before Image Writer (BIW) 


B1W is the only process which writes to the before image (BI) file. BIW 
copies blocks from the before image cache buffer in the SGA to the before 
image file. The copied blocks will be used in the event of a transaction 
rollback, a CPU failure, or a query requiring read consistency. 


Buffer Writer (BWR) 


BWR is the only process which writes to the database and after image 
(AIJ) files. BWR takes modified blocks from the SGA buffer when space 
is needed in the buffer for another block and writes the modified blocks to 
the database, and to the AH file if after image journalling is enabled. 


Cleanup (CLN) 


CLN has two functions: to identify and logoff any ORACLE process 
which has abnormally terminated, and to assist in an orderly shutdown of 
the database. CLN "wakes up" periodically to scan the SGA process in¬ 
formation. If it finds processes which have terminated abnormally, it 
temporarily assumes the identity of the aborted process, and rolls back <uiy 
of its outstanding transactions before logging off of ORACLE on behalf 
of the process. 
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CHAPTER 2. THE ROLE OF THE DATABASE ADMINISTRATOR (DBA) 


This chapter outlines responsibilities and concerns of the person who is re¬ 
sponsible for maintaining an ORACLE database — the Database Adminis¬ 
trator or DBA for short. The two ORACLE DBA users, SYS and 
SYSTEM, are mentioned. 

Oracle Corporation recommends that every ORACLE installation have a 
Database Administrator (DBA) to be the primary liaison with Oracle 
Corporation, and to be a primary source of ORACLE information for us¬ 
ers of the database. The DBA may or may not be the person who installs 
ORACLE; because many however, it is frequently true that the DBA does 
control the installation. 

Strictly speaking, the DBA can be considered to be the user or users who 
have the DBA privilege for the ORACLE database. Each ORACLE sys¬ 
tem is installed with two such users (SYS and SYSTEM); from either of 
these users additional DBA users can be added to an ORACLE system. 

Loosely speaking, the term DBA is often used to describe someone who 
has the best understanding of both the general and detailed pictures of the 
database: for example, who the users are, what data they are storing and 
accessing and how often, what types of transactions are occurring, and how 
to maximize performance. 

Usually in this manual the term DBA implies both of these functions. 
Occasionally the context will require the DBA privilege. 

The main concerns of a DBA include: 

• Guarantee integrity and consistency of data 

• Speed execution and monitor performance 

• Reduce unnecessary or redundant storage 

• Facilitate sharing of common data among users 

• Guarantee security of database 
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• Perform regular database backups. 

Guaranteeing the integrity of the data is a broad topic, which is partly ad¬ 
dressed in the chapters titled "Chapter 9. Consistency and Concurrency” 
on page 131 and “Chapter 12. Using ORACLE Auditing” on page 193. 
*®P£ ov *f 1 8 performance is the general topic addressed by Chapter “Chapter 
10. tuning a System for Performance” on page 151. Controlling and 
monitoring the use of space are discussed in the Chapter "Chapter 8 I low 
is Data Stored in the Database?” on page 97. 


SYS AND SYSTEM: THE ORACLE DBA USERS 


Every ORACLE system is automatically installed with two ORACLE us¬ 
ers who have DBA privileges: SYS and SYSTEM. There are some dif¬ 
ferences in their purposes, as described in the following sections. 

If your site will grant DBA access to many users, or a DBA will be creating 
tables or views for DBA functions, it may be advisable or preferable to 
create additional users with DBA privileges, so as not to take the chance 
of inadvertently altering the tables or views owned by SYS or SYSTEM 
(See Section “Users with DBA Privilege” on page 187 for a description of 
privileges given only to DBA users.) 


User SYS 


1 he ORACLE user SYS is enrolled with the password 
CIIANGE ON INSTALL; the password should be changed immediately 
after system initialization. Changing SYS's password is documented as part 
of the installation process in the Installation and User's Guide for each 
operating system. The syntax is: 

SQL> GRANT CONNECT TO SYS IDENTIFIED BY newpassword; 

As the SYS account owns all of the base tables for the data dictionary and 
these tables are critical to ORACLE'S operation, the SYS account should 
be used rarely, if ever. 

Data in SYS's tables is manipulated by ORACLE as a result of database 
use, not by users. Except as described in the section “ Manually Updating 
the Data Dictionary on page 95, none of these tables should be altered in 
any way by any user. Nor should any ORACLE user create additional 
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tables in the account belonging to SYS. Failure to follow these rules can 
result in destruction of the entire database. 


User SYSTEM 


The ORACLE user SYSTEM is enrolled with the password MANAGER; 
just as for SYS, the password should be changed immediately after system 
initialization. 

Whereas SYS owns all underlying data dictionary tables, SYSTEM owns 
all the data dictionary views. Though the objects owned by SYS I EM are 
somewhat less critical to the operation of ORACLE, it is still strongly re¬ 
commended that they not be altered. 

Some ORACLE utilities create (and require) tables or views owned by 
SYSTEM; these objects should not be altered. A list of such tables/views 
follows (subject to change between versions of ORACLE): 

Additional Tables owned by SYSTEM: 


SQL*P1us 

Help CRT Utility SQL*Forms SQL*Menu 


HELP 


CRT 

CRTBOX 

CRT_PRODUCTS 

CRT_TYPE 

ESC 

FUNCTIONS 

G0T0_LC 

LORC 


IAPAPP 

IAPBLK 

IAPFLD 

IAPMAP 

IAPSQLTXT 

IAPTRG 

IAPTRIGGER 


DMU_APPLICATION 

DMU_COMMAND_TYPE 

DMU_MESSAGE 

MENU_INF0 

MENUJDPTION 

0PTI0N_HELP 

PARAMETERS NFO 

parameter_menu 

USER_INF0 

work_class 


It is also recommended that user data not be stored in tables owned by 
SYSTEM. However, a DBA might reasonably create some additional 
views of data dictionary information in this account. 
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DBA PRIVILEGES 


The users SYS and SYSTEM have special privileges in the ORACLE 
system as do any other users explicitly given DBA access to the database. 
I or a description of these privileges, refer to “Users with DBA Privilege” 
on page 187. 6 
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PART II: USING THE DBA TOOLS 


This part contains several chapters, each of which corresponds to an 
ORACLE program or utility of interest primarily to the DBA. Those 
utilities are: 

IOR for starting and stopping an ORACLE system (a lesser utility, 
SGI, is also described) 

ODS for displaying runtime system statistics 

AIJ for recording database activity for recovery in the event of system 
failure. 

CRT for modifying display terminal characteristics and key mappings. 
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CHAPTER 3. USING THE IOR PROGRAM TO START AND STOP ORACLE 


This chapter describes the different options of the IOR program which a 
DBA uses to start and stop ORACLE. Along with the discussion of IOR 
is a summary and description of the parameters in the INIT.ORA file which 
is read and used by the IOR program. A secondary utility, SGI, is also 
described; the DBA uses SGI to display the memory requirements of par¬ 
ticular INIT.ORA files. 

An ORACLE system need not be running all the time or whenever the 
operating system is up; the DBA can determine when ORACLE is running 
and available. For example, if the DBA needs to increase the size of the 
before image file, he can stop the system at a low-use time to replace the 
file or perform similar maintenance. 

The program named IOR is used to initialize ORACLE (start it the very 
first time after installation) and to start and stop the ORACLE system. 
Usually the DBA is the main or sole user of the program IOR. Because 
the IOR program can be dangerous to the database if misused, very few 
users should have access to run it. Controlling access to the IOR program 
is discussed in the Installation and User's Guide for your operating system. 

Every time IOR is used to start or initialize an ORACLE system, IOR 
reads the INIT.ORA file and configures the system global area (SGA) ac¬ 
cording to the parameter settings in INIT.ORA. The INIT.ORA file and 
its parameters are described after the discussion of the IOR command. 


IOR COMMAND AND PARAMETERS 


The general syntax of the IOR command is shown in Figure 1 on page 
20 . 
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IOR { WARM | SHUT | CLEAR | INIT [ NOCONFIRM ] } [ DBA ] 

[ PFILE= <filename> ] [ SHARED ] [ LIST ] 




Figure I. Syntax oflOR Command 


The arguments are: 

I|NIT| Initialize the database and start the ORACLE detached processes. 
(This is sometimes called a "cold start" as contrasted to a "warm 
start" of the database.) 

W|ARM| Re-start an ORACLE database by starting the detached proc¬ 
esses. 

S(HUT| Check for active database users and shut down (stop) ORACLE 
when all users have logged off ORACLE. 

C[LEAR| Clear ORACLE of all current users and shut it down, without 
waiting for users to log off. Because a CLEAR only terminates 
the background processes, user processes must be stopped at the 
operating system level. 

PFILE= filename Names a file, formatted like INIT.ORA, listing parame¬ 
ters used to start ORACLE. (By default this file is INIT.ORA; 
see “The INIT.ORA Parameter Pile” on page 24.) 

LIST Request that IOR show the parameters in the parameter file 

which would be used to start ORACLE (either the default file, 
or one designated with PFILE). Can be used alone, in which case 
it takes no other action. Can also be used with I, W, S, or C. 

NOCONFIRM Used with INIT option to request that IOR not prompt 
for confirmation that the database be initialized. 

DBA Used with either INIT or WARM to restrict logins to DBA users 
only (until the next IOR W). 

SHARED For shared partition systems only (as for VMS clusters with 
more than one instance running an ORACLE cluster) and used 
with the WARM argument, to indicate that the instance is start¬ 
ing the database in a shared mode. 
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Initializing ORACLE (IOR INIT) 


The initialize option of IOR is used the very first time ORACLE is started, 
to initialize the database files and start the detached processes. Any user 
data which may exist in the database files is lost; an IOR I always restores 
the database and before image files to their original empty state. On most 
operating systems the ORACLE utility CCE is used prior to initialization, 
to create the DB and BI files. After you enter: 

IOR INIT 

a prompt appears to request confirmation of your intention to initialize, to 
which you must respond with the full word YES in upper case: 

IOR: connecting to ORACLE V5.0.20 

Initialize of entire database requested. All data will be lost. 

- Confirm (YES/NO) ? 

To suppress this prompt, use the option NOCONFIRM. When the da¬ 
tabase has been initialized you'll see: 

DATABASE INITIALIZED. 

The INITIALIZE option is used infrequently. Its two most common uses 
are to move to a new version of ORACLE and to reconfigure operating 
system files. If you use the INITIALIZE option on a database which 
contains user data, make sure that you've exported and backed up the DB 
and BI files first. (Refer to the Installation and User's Guide for your op¬ 
erating system for information about doing system backups.) If user data 
is in the database file when an IOR I is run, the data is lost. 

INITIALIZE restores the database to a single partition system. If you 
need to recreate other partitions (for example, when upgrading a multi¬ 
partition system to a newer version of ORACLE), you must do so before 
importing your data. 


Warm Starting ORACLE (IOR WARM) 


A warm start of ORACLE is the normal means of starting an ORACLE 
system, every time but the first (when it is initialized). A warm start opens 
the database files and the before image file, so the files must be online and 
accessible by the account doing the warm start. It also starts the detached 
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processes (ARH, BIW, BWR, and CLN) if the ORACLE system is a 
multi-user system. A warm start also rolls back any outstanding trans¬ 
actions and drops all temporary tables. Because IOR must resolve out¬ 
standing transactions you should never abort an IOR WARM once it has 
started. Though occasionally it may take a while to rollback outstanding 
transactions, it is important that IOR WARM do so. 

When you invoke IOR W, IOR displays the size of the SGA's compo¬ 
nents: 

• number of bytes of fixed data 

• number of bytes of variable data 

• before image buffers 

• database buffers. 

You may also see messages like the following, which indicate normal warm 
start activity: 

n temporary tables deleted 
instance n recovered 

When the warm start has successfully completed, the message: 

ORACLE WARM STARTED. 

will appear. No user will be able to log in to ORACLE until this message 
appears. A user attempting to log in will see the message: 

ORACLE initialization in progress 

Shutting ORACLE Down (IOR SHUT) 


Of the two ways to stop ORACLE, shutting is preferred to clearing. An 
IOR SHU T prohibits new users from logging in to ORACLE, but does 
not affect users currently on; it waits for all current users to log off, and 
then shuts ORACLE down. Also, no new ORACLE user can log on to 
ORACLE. On trying, he will see the message: 

ORACLE shutdown in progress 

Thus, all pending transactions arc completed or rolled back before shut¬ 
down, and the subsequent warm start of the database will not need to 
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rollback any outstanding transactions. During a shut-down, messages may 
appear at the terminal which issued the 10 R S indicating how many users 
are still logged on, such as: 

IOR: 5 users still active 

[or] 

IOR: No active transactions found 

When a shutdown completes: 

IOR: ORACLE shutdown complete 

the detached processes are stopped and the database and before image files 
closed. 

If you wish to terminate a shut-down because it's taking too long, use your 
system's interrupt mechanism. At that point you can do an IOR CLEAR. 


Clearing ORACLE (IOR CLEAR) 


Of the two ways to stop an ORACLE system, an IOR CLEAR is less 
preferred. Clearing ORACLE stops the detached processes immediately 
without waiting for current ORACLE users to log off. Current users are 
not notified that ORACLE is stopping. Transactions currently in progress 
are lost and will be rolled back during the next warm start. 


The DBA Option for IOR 


If the database is started or initialized with the DBA option appearing on 
the IOR command line, then only DBAs can log in to ORACLE (users 
with DBA privilege to the database). This is useful during database 
maintenance operations, such as a full database export or import, when the 
DBA wants to assure that he is the only user of the database. 

If a user without DBA privilege attempts to log on, he'll see the message: 

ERROR ORA-1035: ORACLE only available to users with DBA privilege 

To allow all other users access to ORACLE, the database must be shut 
down and warm started without the DBA option. 
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The SHARED Option for IOR 


The SHARED option applies only for shared partition systems, as in 
ORACLE clusters running on VAXClusters. The SHARED parameter 
must be specified for each instance in the cluster when it is started. If any 
instance starts ORACLE without the SHARED option, no other instance 
can start ORACLE upon trying, but will sec the following message: 

the database is in exclusive use by another ORACLE instance 

If one instance has started ORACLE with the shared option, then every 
other instance wishing to start ORACLE must also use the SHARED 
option to successfully start ORACLE. If an instance tries to start 
ORACLE nonshared (or just forgets to use the SHARED option) and 
another instance has already started it shared, ORACLE assumes that the 
second instance wants it exclusively and isues the error: 

cannot start exclusively; in use by another ORACLE instance 

When a shared partition database is to be extended with the ALTER 
PARTITION command, ORACLE must be run without the SHARED 
option. It is also useful to run without the SHARED option during 
lengthy maintenance operations, such as a full database export. 


THE INIT.ORA PARAMETER FILE 


Every time IOR warm starts (or re-initializes) ORACLE, it reads a file of 
parameters which specifiy characteristics of ORACLE'S operation. By de¬ 
fault that file's name is INIT.ORA; however, any file name can be specified 
on the IOR command line; INIT.ORA is assumed if no file name is en¬ 
tered. Where ORACLE looks for and expects to find the file is operating 
system dependent. In this manual we refer to the INIT.ORA file even 
though you might use a file with another name. 

The INIT.ORA file identifies files used by ORACLE and controls re¬ 
sources which directly affect ORACLE system performance. Eor example, 
it contains parameters which must be given values or named to start a 
system, and parameters which determine the number of entries stored in 
the SGA. By adjusting certain parameters, you can increase or decrease the 
size of the SGA and affect ORACLE'S performance. 
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An example of a short INIT.ORA file is shown in Figure 2 on page 25; 
in this example the names of the database and before image files are 
oracle.dbs and oracle.bi, respectively. (File naming conventions vary by 
operating system; refer to the Installation and User's Guide for your oper¬ 
ating system for additional information about specifying files.) 


processes 

30 

buffers 

50 

database 

oracle.dbs 

before_image 

oracle.bi 

columns 

250 

tables 

50 

enqueues 

200 

users 

30 


Figure 2. Sample INIT.ORA File 

An INIT.ORA file similar to the one in Figure 2 is sent on the release 
tape. Its parameters are adequate for most initial installations of 
ORACLE. After your system is operating and you have some experience 
with ORACLE you may consider changing certain parameters. 

The distributed values for INIT.ORA parameters may vary from the de¬ 
fault values. The distributed values are listed in the Installation and User's 
Guide for each operating system; default values are built into the code and 
will be used if the parameter is not included in the INIT.ORA file. If the 
two values are different and you use the distributed INIT.ORA file as is, 
your system will use the distributed value. 


Adjusting INIT.ORA Parameters 


A few of the INIT.ORA parameters simply name things, such as the data¬ 
base or before image files. Other parameters indicate limits — for example, 
the number of PROCESSES is the maximum number of processes that 
may access ORACLE simultaneously. Some parameters, however, affect 
performance. For example, the setting for TABLES determines the size 
of the tables cache and thus how many table definitions can be cached at 
one time. If a definition is in memory already (in the cache), performance 
will be better than if it is not. 

The parameters shown in Figure 3 on page 26 are called variable parame¬ 
ters, because the size of the SGA varies dependent on their values. These 
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are generally the most important parameters to adjust when tuning a sys¬ 
tem. Some of the variable parameters affect performance but do not im¬ 
pose hard limits; for example, a higher value for BUFFERS usually 
improves performance, but a lower value only slows work; it does not 
prevent it. Some variable parameters also set capacity limits; for example, 
if PROCESSES is 10, the 11th process attempting to log on will not be 
able to. 


VARIABLE 

PARAMETERS 

CAPACITY 

PARAMETERS 

BUFFERS 

TABLE ACCESSES 

COLUMNS 

TABLE HANDLES 

TABLES 

ENQUEUES 

TABLENAMES 

OPEN CURSORS 


PROCESSES 


TRANSACTIONS 


USERS 


Figure 3. Variable and Capacity Parameters 

Increasing the values of variable parameters may improve your system's 
performance, but will also increase the size of the SGA. In virtual memory 
operating systems, an SGA which is too large may degrade performance if 
it is swapped in and out of memory. Operating system parameters that 
control virtual memory working areas should be set with the size of the 
SGA in mind. Exactly which parameters will most benefit your system is 
a function of several database characteristics, such as how your data is ar¬ 
ranged, and how many users or programs are active at one time. Therefore, 
with knowledge of how your system is used, and what these parameters 
control, you can change the variable parameters to see if you can improve 
system performance. 

In the following descriptions, "number" means the maximum number of 
entries that the resource may have in the SGA at any one time (and are 
therefore memory resident). When this maximum is reached, the least re¬ 
cently used entry is replaced by the new entry (and the old entry is available 
from disk). Also note that numbers in INI! .ORA are global, not per user, 
unless otherwise specified. 

For example, if the TABLES parameter is set to 50 in INI I .ORA, the 
SGA can store 50 table definitions. When the 51st table is accessed, one 
of the old tables definitions is replaced by the definition for the 51st table. 
If three users are using the table SCOTT.EMP, only one entry of the TA¬ 
BLES parameter is required for the table. 
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You may see error messages indicating that a parameter is too low or that 
you have reached the maximum. For example: 

insufficient enqueues 
out of processes 

insufficient table cache entries 
insufficient tablename cache entries 

If a message occurs repeatedly, you can avoid the message by shutting 
down ORACLE, increasing the relevant I NIT.OR A parameter and re¬ 
starting ORACLE. Alternatively, you can wait a bit and retry the opera¬ 
tion when the system is not as busy. 


Operating System Dependent Parameters 


This guide contains the most thorough description of the INI I .ORA pa¬ 
rameters; however, many of the parameter values or ranges are dependent 
on the operating system. For example, the parameter BUFFERS indicates 
the number of data buffers in main memory; the size of those buffers,^ 
however, is system-dependent. Refer to the Installation and User s Guide 
for your particular operating system to see operating system specific infor¬ 
mation on the INIT.ORA parameters. 

Note that many INIT.ORA parameters should not be altered. 


UNIT.ORA Parameter Detailed Descriptions 


The following sections describe each INIT.ORA parameter in detail. 
“Appendix D. Summary of INIT.ORA Parameters” on page 229 contains 
a summary of the INIT.ORA parameters. 


AI BUFFERS 


This parameter indicates the number of after image buffers. The default is 
3 and should not normally be altered. This parameter has no effect in 
ORACLE V5.0. 


AFrER IMAGE „ . 

This parameter specifies the directory or filename for after image journal 
files. The default and distributed parameter arc null. If present, this pa¬ 
rameter enables after image journalling. I his parameter can appear more 
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than once in the INI I .ORA file, if there are multiple journal files. Journal 
tiles are used in the order they appear in the INIT.ORA file. 

For more information on AIJ, refer to “Chapter 5. After Image Journalling 
(AIJ) on page 59. 5 


AI_FILE_SIZE 

This parameter specifics the size of journal files in ORACLE blocks. If it 
is set to zero or not specified, then journalling is done to the fixed size files 
named in the AFTER IMAGE parameter. If it is set to a non-zero 
number, journal files are created, with names in the form SQNnnnnnn.AIJ, 
whose size is the indicated number of Kbytes, in the directory(ies) indicated 
m AFTER_IMAGE. The default value is 0. 

For more information on AIJ, refer to “Chapter 5. After Image Journalling 
(AIJ)” on page 59. 

AI_WARN_PCNT 

When the AIJ file reaches this-perccnt-full" a warning message is sent to 
the operator console (OPER1 on VMS). The default percent is 0. If all 
specified after image files are full or the directory becomes full when 
journalling is enabled, ORACLE should be shut down, a backup taken, 
and the AIJ files refreshed, before restarting ORACLE. 

For more information on AIJ, refer to “Chapter 5. After Image Journalling 
(AIJ)” on page 59. 


AUDITTRAIL 

I his parameter enables or disables the writing of rows to the audit trail. 

If set to a non-zero integer, auditing is enabled. If set to zero or if not 
present, auditing is disabled. The default value is 0. The SQL AUDIT 
statements can be used regardless of the setting. 

For more information on auditing, refer to “Auditing” on page 193. 

BEFOREJMAGE 

This parameter specifies the name of the before image file. The file must 
be created (on most operating systems via the ORACLE CCF utility) and 
a name specified to run IOR. The default is system dependent. 

BI_BUFFERS 

This parameter indicates the number of before-image buffers. The default 
varies by operating system, and should not be altered. 
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BIHIGH 



This parameter is used by shared-partition systems, such as VMS systems 
using VAXClusters. It indicates the ending block for an ORACLE in¬ 
stance's before image file area. The default is the end of the before image 
file. This parameter is set during installation of shared-partition systems, 
but may be modified by the DBA. On VMS it is automatically set when 
CREINIT.COM is run. (BILOW indicates the starting block.) 

[BLOW 

This parameter is used by shared-partition systems, such as VMS systems 
using VAXClusters. It indicates the starting block for an ORACLE in¬ 
stance's before image file area. The default is the beginning of the before 
image file. This parameter is set during installation of shared-partition 
systems, but may be modified by the DBA. (BI_HIGH indicates the 
ending block.) 

BLOCK_SIZE 

This parameter indicates the size of the database block. The default varies 
by operating system, and should not be altered. The two typical block sizes 
are 2048 bytes (on minicomputers such as DEC VAX/VMS, Data General 
AOS/VS, and many UNIX environments), and 4096 bytes (IBM VM/SP 
or MVS environments). 

BUFFERS 

This parameter specifies the number of data buffers cached in main mem¬ 
ory. (The size of a data buffer is operating system dependent; on VMS it 
is 2K.) The default is 50. Modified buffers arc forced written to disk when 
a commit, rollback, logoff, or dictionary operation (DDL) is performed, 
or when the buffer cache is full. Though there is no maximum limit to this 
parameter, the value chosen has a direct impact on the size of the SGA. 

The more buffers, the more likely it is that data will be found in memory 
and thus the less I/O ORACLE will have to do. 

BIJFF_HASH_BKTS 

This parameter specifies the number of entries in the hash table used to find 
ORACLE buffers. This parameter should not normally be specified. If 
omitted, it is calculated based on BUPPERS. The default value is from 1 
to 32, depending on BUPPERS. If you do specify a value, it will be ad¬ 
justed to a power of 2. Por most systems, the value chosen should be such 
that the following relationship is true (the ratio of BUFFERS to 

BUFF IIASH BKTS is between 4 and 8): 
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BUFFERS 

4 <= - < = 8 

BUFF_HASH_BKTS 

Ix)wer values of this ratio will result in slightly faster lookup at the expense 
of more randomness in the caching algorithms (and might be more appro¬ 
priate for very large databases). Greater values of this ratio will result in 
slightly slower lookup. Though the value 1 is also acceptable, it is proba¬ 
bly appropriate only for very small systems. 

CLUSTERS 

This parameter specifies the number of cached cluster definitions. It is set 
to the number of different clusters typically in simultaneous use. The larger 
the cache, the more likely it is that ORACLE will find the definition of a 
cluster in memory rather than requiring dictionary accesses. This will re¬ 
duce parse execution time. The default value is 20. If you alter CLUS¬ 
TERS, include one extra to account for the cluster used by the data 
dictionary. The value used for CLUSTERS affects the size of the SGA, 
though the size per cluster definition is small. 

COLUMNS 

This parameter specifies the number of column definitions cached in the 
SGA (required by number of tables, clusters, and views concurrently ac¬ 
cessed). It must be large enough for the largest (widest) table. The default 
(350) is calculated as five times the sum of CLUSTERS plus TABLES. 

If you alter COLUMNS, include 50 as overhead for the data dictionary 
tables. The value used for COLUMNS impacts the size of the SGA. The 
larger the cache, the more likely ORACLE is to find a column definition 
in memory, thus improving performance. 

CONSOLE 

This parameter is not currently used. 

CONTEXTJNCR 

This parameter indicates the number of bytes by which the context area 
will grow when it is full and requires more space. The default increment 
is 4096 bytes; the minimum is 1024 and the maximum is usually 32768, 
but is operating system-dependent. 

CONTEXTJSIZE 

This parameter specifies the initial size of the context area. The minimum 
is 1024 and the maximum is usually 131072, but is operating system- 
dependent. The default is 4096 bytes. 
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DATABASE 

This mandatory parameter names the primary database file, which corre¬ 
sponds to the first file of the SYSTEM partition. The file must be created 
(on most operating systems via the ORACLE utility CCE) and a name 
specified to run IOR. The default is system-dependent. 

I>ETACHED_I)UMPS 

(This parameter is not applicable to single-process systems, such as 
MS-DOS.) 

This parameter names the logical or physical directory where dumps for 
detached processes are written. The default is system-dependent. 

ENQUEUES 

This parameter indicates the maximum number of total enqueue entries. 
Enqueues are a locking mechanism for shared resources. Each request for 
a resource (table, row, etc.) must obtain an enqueue on that resource before 
any operation may be performed. All subsequent requests for that same 
table, for example, will be added to the enqueue list for that table, to con¬ 
trol locks on that table. 

Each database cursor requires one enqueue per table accessed plus one per 
table updated plus one per row locked. The default is 5 times PROC¬ 
ESSES. 

FILES 

This parameter indicates the maximum number of database files which 
may be opened in the SGA. Each partition and subsequent partition ex¬ 
tent counts as a file. For example, one file in one partition takes one entry. 
The default is 5; the maximum is operating system dependent. 

FIXEDDATE 

This parameter, usually used for testing only, fixes ORACLE s internal 
SYSDATE. The parameter's format is YYYY, MM, DD, HH, MM, SS. 
For example, to set noon Apr 1, 1986 the parameter would be entered as 

1986, 4, 1, 12, 0, 0 

The default is null, which indicates that the current date is supplied by the 
operating system. 

INSTANCES 

Applicable only for shared-partition operation (such as VAX/VMS clus¬ 
ters), this parameter indicates at IOR I time the maximum number of 
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INSTANCE NAME 


LANGUAGE 


OPEfr CURSORS 


OPENLINKS 




ORACLE instances allowed to use this database. The default and maxi¬ 
mum are 16; all instances need not be used or running. This parameter 
should not normally be specified. For more information, VMS users 
should see the ORACLE for DEC VAX I VMS Installation and User's 
Guide. 


Applicable only for shared-partition operation (such as VAX/VMS clus¬ 
ters), this parameter identifies a particular ORACLE instance. On VMS 
the CREINIT.COM procedure sets the instance name by appending its 
system id (SID) to SYSTEM , as in: 

SYSTEM_S 

This parameter should not normally be specified. 


This parameter allows you to define a native language such as "ENGLISH" 
or "FREvNCII". By default this parameter is null but it may be set to any 
alphanumeric string up to 15 characters. The parameter communicates the 
name of the language to applications through the USERENV function. 
When encountered in a SQL statement, the value of: 

USERENVCLANGUAGE 1 ) 

is the language name specified in the language parameter, converted to 
upper case. At present the parameter serves no other purpose (such as af¬ 
fecting collating sequence or date formatting). Because ORACLE docs not 
interpret the parameter string, the meaning of various values is up to the 
user. 


This parameter indicates the maximum number of cursors that each user 
is allowed to open. It does not affect the SGA size. I he default is 50 and 
valid range is 10 to 255. 


This parameter indicates the maximum number of database links in si¬ 
multaneous use by a user's session. Thus, a parse will fail if the number 
of different database names specified by all parsed cursors exceeds the limit. 
By default the limit is 4. 
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PROCESSES 


READBLKSREQ 


READ_BLKS_TOT 


READ_REQUES1S 


SINGLE_PROCESS 


SORT_AREA_SZ 


This parameter sets the maximum number of possible concurrent 
ORACLE processes. To calculate, allow one process per ORACLE logon, 
and overhead of 5 (one each for the detached processes, if running in 
multi-user mode, and one for 10R). The maximum and default are oper¬ 
ating system dependent. The minimum for single-user systems, such as 
MS-DOS, is 2. The value set for processes is used to calculate several other 
parameters. 


(This parameter is not applicable to single-process systems, such as 
MS-DOS.) 

This parameter specifies the number of blocks that may be requested in a 
single read request. The valid range is 0 to 255; the default value is 10 or 
READ BLKS TOT, whichever is smaller. You should not normally alter 
this parameter. 


(This parameter is not applicable to single-process systems, such as 
MS-DOS.) 

This parameter specifies the total number of blocks that may be in out¬ 
standing background read requests at any time. I’he default value is set to 
one-half of BUFFERS. It is recommended that you not specify this pa¬ 
rameter. 


(This parameter is not applicable to single-process systems, such as 
MS-DOS.) 

This parameter sets the maximum number of outstanding concurrent 
background read requests to be processed by AR11. I he default value is 
equal to PROCESSES, or 5, whichever is greater. It is recommended that 
you not specify this parameter. 


If this parameter is non-zero, ORACLE will run in single-process mode 
with no detached processes. The default is 0. You should not normally 
alter this parameter. 


This parameter indicates the size in bytes of real memory which can rea¬ 
sonably be expected to be available for sorting. For example, on a VAX 
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with 8 megabytes of real memory, of which you think 1/8 might be avail¬ 
able to sorting processes, and you expect to have about 4 sorts occurring 
at once, you might set this parameter to 8192/8/4 = 256K (converted to 
bytes). As a rule, a a larger size will only improve the efficiency of large 
sorts. The default is operating system dependent and is usually fine for 
most database operation. Only if very large indexes are being created might 
you want to adjust this parameter. Por example, if one process is doing 
all database access, as in a full system import, then an increased value for 
this parameter may speed the import, particularly the CREATE INDEX 
statements. 

SORT 

FINALRA 

This parameter indicates the readahead depth factor during final sort 
passes. The default is operating system dependent and should not normally 
be altered. 

SORT 

_mi;rge_ra 

This parameter indicates the readahead depth factor during intermediate 
sort passes. The default is operating system dependent and should not 
normally be altered. 

SORT 

_POOI,_SZ 

This parameter is no longer used. 

SORT 

readjac 

This parameter indicates the multi-block read factor for sorting. It should 
not normally be altered. 

SORTSPCMAPSZ 

This parameter indicates the size in bytes of the sort spaccmap in context 
area. The default is operating system dependent and is usually fine for 
most database operation. Only if very large indexes are being created might 
you want to adjust this parameter. The sort automatically increases its 
space map when necessary, but it won't necessarily do it at the point when 
it will make best use of disk storage. The sort will make optimal use of 
disk storage if SORT SPCMAP SZ is set to: 



[(total-sort-bytes) / (sort-area-size)] + 64 



where total-sort-bytes is: 
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(number-of-records) 

[sum-of-average-column-sizes + (2 * (number of col))] 

where columns include the SELECI list for the ORDER BY, the SE¬ 
LECT list for the GROUP BY, and the key list for CREATE INDEX. 

Also include 10 bytes for ROWID for CREATE INDEX and any. 

GROUP BY or ORDER BY columns not mentioned in the SELECT list 
for these cases. The value is in bytes so a very small value will not gain 
you much. 

SQL 

This parameter names the file to be used during an IOR INIT. 1 he default 
is SQL.ORA. 

TABLEACCESSES 

This parameter indicates the number of tables being used. Count one foi 
each distinct table in use by all cursors in the system. Por example, if 60 
different processes were all accessing the table DEPT, it would require 1 
TABLE ACCESS. The default depends on PROCESSES, ranging from 

8 to 208 for 1 to 40 processes. 

IABLL_U ANDLES 

This parameter indicates the number of simultaneous table uses by all 
cursors. Count one for each reference to a table by a cursor plus one for 
each update to a table by a cursor. For example, if 60 processes each had 

3 cursors open on the DEPI table, it would require 180 
TABLEJIANDLES (but just 1 TABLE ACCESS). Or, if one user were 
executing the following query: 

UPDATE EMP 

SET SAL = SAL * 1.15 

WHERE DEPTNO IN 

SELECT DEPTNO 

FROM DEPT 

WHERE LOC = 'NEW YORK' 

then table accesses would be two and table handles would be three. If two 
users were executing the same query, table accesses is still two but table 
handles would be six. The default is 8 per process, with a minimum of 24. 
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TABLE_HSH_BKTS 

This parameter specifies the number of entries in the hash table used to fmd 
table access entries. It is generally preferred not to specify this parameter. 
If omitted, it is calculated based on TABLEACCESS ES. The default 
value is from 1 to 32, depending on TABLE_ ACC ESSES. If you do 
specify a value, it will be adjusted to a power of 2. For most systems, the 
value chosen should be such that the following relationship is true (the ra¬ 
tio of TABLEACCESSES to TABLEHSIIBKTS is between 4 and 8): 

TABLE_ACCESSES 

4 <= - <= 8 

TABLE_HSH BKTS 


TABLENAMES 

This parameter specifics the maximum number of tabic, view, and syno¬ 
nym names which can be cached in the SGA simultaneously This cache 
keeps track of the mapping between an object (tabic, view, or synonym) 
name and a table identifier. I he default is 80. If altered, allow an overhead 
of 10 for the dictionary tables. The larger the value, the more likely 
ORACLE is to find the name of the requested table in memory, thus re¬ 
ducing parse execution time. 

TABLES 

This parameter specifies the maximum number of cached table definitions. 
The default is 50. The larger the value, the more likely ORACLE is to find 
the definition of the requested table in memory, thus reducing parse exe¬ 
cution time. If altered, allow as overhead 10 for the dictionary tables. It 
should reflect the maximum number of tables and views expected to be in 
use at any one time. 

TEMP FABLES 

This parameter specifics the number of temporary tables which ORACLE 
will maintain, once created, after a warm start. It is not the maximum 
number of temporary tables which can be created, though any created 
above this limit are deleted as soon as possible. At an IOR WARM all 
temporary tables are dropped, to be created as they arc required. Ihe de¬ 
fault is one-tenth of the lesser of TABLEJIANDLES or 
TABLE_ACCESSES. Zero is a valid setting. 

TRANSACTIONS 

Hus parameter specifies the maximum number of concurrent transactions. 
For more information about transactions, sec “Logical Units of Work 
( Transactions)” on page 131. The default value is 5 times PROCESSES. 
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user ini r 

This parameter specifics the name of the file to be executed after the file 
specified by the SQL parameter. The default value is null. If specified, it 
is expected that this file contains SQL statements. It is also assumed that 
the account running the file is SYSTEM/MANAGER. The file may not 
contain any CONNECT statements. Many sites run CATALOG.ORA 
(the file which creates the data dictionary views) by specifying it here. 

USERS 

This parameter specifies the maximum number of cached user names (not 
the maximum number of users concurrently logged on). It reflects the ex¬ 
pected maximum number of users referenced in SQL statements. A user 
name is stored only once. I he default value is 30. I he larger the number 
the better the performance in environments with a large number of distinct 
ORACLE usernames; however, there is no need for this parameter to ex¬ 
ceed the value for PROCESSES. 

Ljser_dumps 

This parameter specifies the file or directory where error trace dump files 
for user processes are written (such as for IAP, ODL, RPI, etc.) I he de¬ 
fault is operating system dependent. 


USING A DIFFERENT PARAMETER FILE 


It is easy to change the parameter file used to start ORACLE. Every time 
ORACLE is started, IOR looks for cither the file named on the IOR 
command line or a file named INI 1 .ORA. So, you can have multiple files 
in the same format as INI I .ORA but with different names, or you can 
change one IN FLORA file over time until you arc satisfied with the pa¬ 
rameter settings. 

To avoid confusion when changing parameter files, it is preferable to not 
alter a parameter file which was used to start a currently running ORACLE 
system. Instead, shut ORACLE down before editing the file and restarting 
ORACLE. Alternatively, you can create and edit a totally new parameter 
file, stop ORACLE, and restart with the new file. You must warm start a 
system in order for a new parameter file to take effect. 
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ERRORS RETURNED DURING IOR 


Errors returned during IOR are frequently access errors due to ORACLE 
encountering problems finding or accessing the proper database or before 
image files. Because these errors tend to be operating system specific, 
please refer to the Installation and User's Guide for your particular oper¬ 
ating system for a list of the errors and recommended actions. 
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THE SGI UTILITY 


The SGI utility is a simple utility for DBAs to test the size of the SGA 
generated by different parameter files. T he SGI utility displays the size of 
the System Global Area (SGA) that will be generated by a parameter file. 
The size is broken down according to fixed data and variable data. 

I he size required by the SGA varies depending on the settings indicated for 
the various parameters. Of the almost 50 possible parameters which can 
be specified in INIT.ORA, many require space in the SGA (see Figure 3 
on page 26). Some parameters require much more space than others. 


Invoking SGI 


The syntax for SGI is: 

SGI [PFILE=parameter_file] [LIST] [DETAIL] 

where: 

parameterJile is the name of a parameter file for an ORACLE system. If 
not indicated, INIT.ORA is assumed. If a different filename is 
given, its contents should be in the same format as the 
INIT.ORA file distributed for your operating system. 

list displays the settings in effect for the indicated or assumed pa¬ 
rameter file. (T his display is identical to that resulting from 10R 
LIST). Either the distributed value for each parameter or the 
value indicated in the specified parameter file appears. (Values 
taken from the parameter file arc marked with an asterisk +.) 

detail displays the total size, in bytes, which particular parameters or 
groups of parameters require. 


The SGI Output 


The default listing from SGI gives the name of the parameter file and a 
summary of the bytes used in the SGA. Figure 4 on page 40 shows an 
example which was taken from an IBM VM/SP ORACLE system. 
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sgi pfile=init.ora 

SGI: System global area (SGA) is 327212 (320K) bytes composed of 
2172 bytes of fixed data 
71088 bytes of variable data, 

40960 bytes of before image buffers, and 
212922 bytes of buffers. 

R; T=0.04/0.11 10:16:06 ___ 


Figure 4. Fxamplc of an SGI Display 


An example of the LIST option (invoked in an IBM VM system) appears 
in Figure 5 on page 41. 


sgi pfi1e=init.ora list 
Parameter file: INIT.ORA 
Parameters used to start system: 


after_image 


ai_file_size 

0 

ai_warn_pcnt 

0 

* audit_trail 

1 

* before_image 

*.1F1. 

bi_buffers 

5 

bi_low 

0 

bi_high 

0 

block_size 

4096 

* buffers 

52 

buff_hash_bkts 

8 

clusters 

20 

* columns 

400 

console 


context_incr 

4096 

* context_size 

16384 

* database 

*. 1F1 

detached_dumps 


... [continued 

on nex 
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* enqueues 

200 

* files 

10 

fixed_date 


instance_name 


instances 

16 

* open_cursors 

150 

* processes 

10 

read_requests 

10 

read blks_tot 

26 

read blks_req 

10 

sort_area_sz 

65536 

sort_pool_sz 

0 

sort_merge_ra 

1 

sort_final_ra 

1 

sort_spcmap_sz 

256 

sort_read_fac 

10 

single_process 

0 

* sql 

SQL.ORA 

* tables 

150 

tablenames 

80 

* table_handles 

150 

table_accesses 

80 

table_hsh_bkts 

16 

temp_tables 

8 

transactions 

50 

user_dumps 


users 

30 

userinit 



Figure 5. Example of the LIST option of SGI 

To sec more (leta.il about SGA variable data use the DIG AIL option of 
SGI. The DETAIL option of SGI breaks down the SGA's total size into 
bytes required by particular parameters. Be careful about drawing conclu¬ 
sions about the number of bytes required per parameter, for the following 
reasons: the number of bytes required varies by operating system. Some 
sizes include an overhead number of bytes per parameter, so by dividing 
total size by number of units will result in a wrong unit size. Though you 
cannot easily determine the "unit size" of a parameter, the SGI DETAIL 
option allows you to see which parameters have more effect on the SGA s 
size (and therefore achieve somewhat better control over the eventual size). 
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Figure 6 on page 42 shows the output from SGI DE TAIL. 


sgi pfile=init.ora detail 
Size IOR Parameter 


660 after_image 
308 read_requests 

112 <before image control: not an IOR parameter> 

2548 buffers, buff_hash_bkts 
19200 columns 
3840 table_names 
1200 users 
2600 files 
320 clusters 
8400 tables 
4800 enqueues 

480 processes (cache buffer ownership) 

1800 transactions 

1600 processes (transaction framing) 

3440 processes (control blocks) 

19664 table_handles, table_requests 
0 fixed_date 

0 <internal locks; not an IOR parameter> 

116 <internal queues; not an IOR parameter> 

SGI: System global area (SGA) is 327212 (320K) bytes composed of 
2172 bytes of fixed data 

71088 bytes of variable data, 

40960 bytes of before image buffers, and 

212992 bytes of buffers. 

R; T=0.06/0.17 10:12:13 _ 


Figure 6. Example of DETAIL option of SCI 
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CHAPTER 4. THE ORACLE DISPLAY SYSTEM UTILITY (ODS) 


This chapter describes the ODS program which is useful to monitor ongoing 
use of an ORACLE system. Different screens may be selected to indicate 
which users are active, which locks they arc holding, and how much activity 
has occurred in the database since the last warm start (IOR W). Of par¬ 
ticular interest are the screens showing information about current locks, and 
the before image file. 

(This section can be skipped by users of single-process systems, such as 
MS-DOS.) 

Using ODS you can see: 

• which processes (O/S users) are currently using ORACLE 

• what ORACLE programs they are using (SQL+Plus, SQL*Forms, EXP, 
etc.) 

• what tables they are accessing 

• what locks they are holding or waiting for 

• the current status of the before image file 

• logical and physical I/O activity. 

ODS also allows you to send the display screens to a file. These "snapshot" 
files may be used to spot trends or trouble spots in a site's use of 
ORACLE. 
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INVOKING ODS 


To use ODS, enter the command ODS at the operating system level. You 
will see a screen like the following: 


ODS: Version 5.0.20 on Thu Apr 3 09:29:59 1986 

Copyright (c) 1985, Oracle Corporation, California, USA. All rights re¬ 
served. 

ORACLE Display System 
Choose display type: 


NOTE: Most screen examples in this section are taken from ORACLE 
under VAX/VMS; the ODS screen appearances and information vary by 
operating system, but are very similar. 

To see a list of valid responses type I l(elp). The response is the screen 
shown in Figure 7 on page 45 which lists your options. 

Responses can be abbreviated to the first one or two characters. If you 
choose a display option, the chosen display will appear on the terminal 
screen. Enter E(xit) to exit to the operating system. To change or reset 
the display cycle interval, enter CY(clc) and specify a cycle time in seconds 
as a command argument. T he valid cycle range is between 1 and 600 sec¬ 
onds. You can change the interval between displays. Use your system's 
interrupt sequence to return to the ENT ER DISPLAY screen. 
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ORACLE Display System 

Choose display type: 

Commands: Help (or ?) - this display 

Bi - Before Image file statistics 
CLose - Close the log file 

CYcle <n> - set the update interval to 'n' seconds 
Exit - exit from ODS 

Io - System I/O distribution on per user basis 
Locks (0) - Lock and Enqueue lists (0=all locks) 

Open <filename> - Open the log file 
[VMS:] Process - Process, user, terminal, and image statistics 

[VM: ] Process - VM summary information 

Summary - Summary of ORACLE system activity 
Table - Tables accessed by each user (D=RBA in dec) 

User <first-pid> <last-pid> - Detailed user stats 


Figure 7. The ODS Options Screen 

The following sections describe the various screens and the information 
they relay. Note that you can direct the output to a file which is useful for 
system evaluation or problem determination. 


USING AN ODS LOG TILE 


You can save what appears on ODS screens into a file. Log files are easy 
to read and a convenient way of monitoring use. To start writing to the 
log file, enter the Open command to the prompt for display type. You can 
enter a specific log file name, or use the default. The default filename is 
ODS.LOG. To close the log file, return to the display menu screen and 
enter the Close command. 
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THE ODS DISPLAY SCREENS 


Following are descriptions and examples of the ODS display screens. The 
two screens of most interest to users are ususally considered to be the 
Locks Display and the Before Image Display. 

The Before Image Display 


The Before Image screen is useful for seeing how many blocks of the before 
image file are in use or available. An example of the Before Image screen 
follows: 




BEFORE IMAGE STATUS 

09:38:38 


Used blocks 

0 



Low block 

1 



High block 

625 



Head block 

96(3) 



Tail block 

622(3) 



Figure 8. The Before Image Display 


The before image file is treated as a "circular file"; that is, blocks are used 
sequentially as needed, and when the last block is used, ORACLE starts 
reusing blocks beginning with the first. Each time it goes through the BI 
file, ORACLE has made one pass. 


Transactions allocate blocks as needed, rather than in sequential sets of 
blocks; thus blocks for one transaction arc interspersed among blocks for 
other transactions, as in: 

TAIL 


block _ 

number 

transaction 

ID 


1 

2 

. . . 

A 

A 

B 

C 

A 

B 

B 

C 

A 

C 

C 


















624 

625 


HEAD 

When a transaction commits, the blocks it has used are freed for reuse; 
however, a block is only really available for reuse if no blocks before it are 
currently being used. Thus, in the previous BI file, even if transaction B 
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commits first, thereby releasing B's blocks, transaction A must commit 

before transaction B's blocks are available for use by another transaction. 

Used blocks Number of before image blocks actually in use by active 

transactions. If it is 0, no active transactions require blocks in the 
before image file. This number does not indicate where those 
blocks are in the before image file; the blocks in use may be 
contiguous or fragmented. If they are contiguous (as from only 
one active transaction) then all remaining blocks are currently 
available. If they are fragmented, then some blocks are not cur¬ 
rently being used but are not yet available for use. 

Low, High blocks The fust and last blocks of the BI file allocated to this 
instance. Unless the screen is displayed for an ORACLE instance 
running an ORACLE cluster, these values will correspond to the 
entire BI file. 

Head block This block number indicates the last block allocated to a cur¬ 
rent transaction. The Head Block's value is updated every time 
another BI block is required. 

The number in parentheses is the pass number. The pass number 
offers little information to users, only telling the number of times 
ORACLE has "wrapped around" the BI file (similar to a counter 
indicating how many times a car's odometer has turned over). 

Tail block This block number indicates the earliest block allocated to a 

current transaction. The Tail Block's value is updated only when 
more space is required which "runs in to" the current tail block; 
thus it is only updated when another pass is made in search of 
available blocks. T herefore, this value is most meaningful when 
it has just been updated. 

To figure out how many blocks are available for use, use the following 

formula: 

(Tail Block - Head Block) = n 

If n is POSITIVE, then n blocks are available. 

If n is NEGATIVE, then add (High Block - Low Block) 
to n to get the number of blocks available. 

Some examples will illustrate how to use the screen. In Figure 8 on page 

46 we see: 

• The BI file has a total of 625 blocks (going from Low Block 1 to High 
Block 625). 
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• There are no current transactions which require BI blocks (Used Blocks 
is 0). 

• The current Head Block is 96, which means that blocks starting at 97 
on are available for use. 

• The current Tail Block is 622, which means that the last time ORACLE 
required BI space, blocks beginning with 622 were in use. However, 
since Used Blocks is now 0, we can assume that Block 622 is available 
as are all blocks -- it's just that the Tail Block value hasn't been updated 
because no transactions have requested space. 

If any blocks were currently in use, the before image file might look 

something like: 


I available 


unavailable 
/in use 



m 

17/ 


17. 

’ S f f 

7 

/ / s / 

m 

17/, 























'W/ 

S3 



In the previous example, the Tail Block number was greater than the Head 
Block number. Take another example where the Head Block is greater 
than the Tail Block: 


BEFORE 

IMAGE STATUS 

02:47:11 

Used blocks 

450 


Low block 

1250 


High block 

15000 


Head block 

3800(7) 


Tall block 

2800(6) 



• The BI file has a total of 13750 blocks (going from Low Block 1250 to 
High Block 15000). 

• Current transactions require 450 blocks (Used Blocks is 450). 

• The current Head Block is 3800, which means that blocks starting at 
3801 and on are available for use. 

• The current Tail Block is 2800, which means that the last time 
ORACLE required BI space, blocks beginning with 2800 were in use. 

If Tail Block has just been updated, then we know that an active trans¬ 
action is now using block 2800. If Tail Block has not just now been 
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updated, then the transaction using block 2800 may have committed that 
block (and others), freeing up more blocks. 

• Using the formula to determine how many blocks are available, we see: 


2800 - 3800 = -1000 so we add (15000-1250)=13750 
to get 12750 known available blocks 


The usage of this before image file, assuming that Tail Block has just been 
updated, might look like: 


] available 



unavailable 
/in use 


1250 






2800X 

f s * / 

m. 

m 

Wa 

W/, 

Wa 

m 

3800 / 

f ss// 

7 

/ 


















15000 


The I/O Display 


The 1(0) display is a histogram of the percentage contribution of each 
ORACLE process to the total amount of logical and physical I/O during 
the specified period. Each ORACLE process is identified by a Process ID 
or FID. 


-Interval- 


ORACLE SYSTEM 1/0 DISTRIBUTION 
- -Cumulative- 


10:15:54 


Log Reads Phy Reads Log Writes 
0 % 100 0 % 100 0 % 100 


Log Reads Phy Reads Log Writes 
PID 0 % 100 0 % 100 0 % 100 



Figure 9. The 1(0) Display 
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Because this is a graphics display running on systems that do not neces¬ 
sarily support graphics, this display is designed to show only relative dis¬ 
tributions of I/O activity across processes. It is not intended to be an 
accurate view of the precise distribution patterns. 


The Locks Display 




If you have many locks, you can have the locks display page through all 
locks by invoking the display with a zero argument, as in: 



L 0 




The Locks display returns: 




09:30:15 


ORACLE 

LOCK DISPLAY 

S = shared s = shared wait 


9 Active locks 

! 6 Processes 

X = exclusive x = exclusive wait 

DDL 

.1. 

fO s 


table access(TAC) 

X 


DML 

.1. 

8c X 


DML 

.1. 

19 X 


CTL 

.4. 

.0 X 


CTL 

.2. 

.0 X 


DDL 

,...20000. 

.0 X 


DDL 

.1. 

c8 X 


DDL 

....10000. 

.0 X 



Figure 10. The Locks Display 

Sec “ORACLE Locks” on page 136 for descriptions of the various locks 
which will appear in this display, including how they arc represented in this 
display. Each lock in this display represents one enqueue entry in the 
SGA. 

upper case x (X) An exclusive lock currently held by a process. 
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lower case x (x) A process is waiting for an exclusive lock. 

upper case s (S) An shared lock currently held by a process. 

lower case s (s) A process is waiting for a shared lock. 

(C TL) Protects the database and before image file when multiple in¬ 
stances are accessing a database. In non-shared partition systems, 
BIW and BWR will always hold exclusive CTL locks. 

DDL locks Indicate a number of locks called "dictionary/parse" locks. The 
various DDL locks are described in detail in “Dictionary/Parse 
Locks (DDL Locks)” on page 141. 

DML locks Indicate a number of locks called "table/row" locks. The vari¬ 
ous DML are described in detail in “Table/Row Locks (DML 
Locks)” on page 143. 


ORACLE LOCK DISPLAY 


6 

Active 

locks ! 

6 Proces 

_ O 0 A C C. 

DDL. . 

.1. 

.f 0 

s 

DDL. . 

.1. 

....2b4 

s 

ROW.. 

. .15b0. 

. .10001 

X 

CTL. . 

.4. 

.0 

X 

CTL.. 

.2. 

.0 

X 


09:41:53 

S = shared s = shared wait 

X = exclusive x = exclusive wait 

+-+- 


Process 6 has exclusively locked a record for future use - record with 
ROWID "000015b0.0001.0001" (the first record inserted into logical block 
15b0 of the first partition). 


The Process Display 


The Process screen contains operating system specific information about 
users currently logged in to ORACLE. Processes 2 through 5 are always 
BWR, BIW, CLN, and ARII in a multi-user system. 

To run this display under your operating system may require certain priv¬ 
ileges; check the installation guide for your operating system if the screen 
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does not appear similar to the example. For example, running this display 
without the necessary privileges on VAX/VMS results in a screen showing 
only one line containing information about your own process. 

On VAX/VMS the Process screen looks like: 


VAX PROCESS INFORMATION 


ORA 


PID 

VAX PID 

USER NAME 

TERM 

1 

? 

13b0054 

ORACLE 



3 

10b0057 

ORACLE 


( 

4 

lld0053 

ORACLE 


1 

5 

630051 

ORACLE 



7 

148004f 

TED 

TTA5 

j 

B 

8e0042 

CAROL 

RTA1 

i 

9 

C70043 

ALICE 

TXG2 

H 

0 

6a0044 

DBA 

TKA2 


IMAGE 


USER$DISK1:[ORACLE.V5C0DE]BWR.EXE;1 
USER$DISK1:[ORACLE.V5C0DE]BIW.EXE;1 
USER$DISK1:[ORACLE.V5C0DE]CLN.EXE;1 
USER$DISK1:[ORACLE.V5C0DEjARH.EXE;1 
DRBO:[ORACLE.V5C0DE]IAP.EXE;1 
DRBO:[ORACLE.V5C0DE]RPT.EXE;1 
DRBO:[ORACLE.V5C0DE]IAP.EXE;1 
DRBO:[ORACLE.V5C0DE]0DS.EXE;1 


Figure II. The Process Display 

Under IBM VM/SP the Process screen looks like: 






VM/SP PROCESS INFORMATION 

10:16:17 

ORA 

, PID 

VM User 

VM Termid 

ORACLE Userid 



2 

ORABWR 

DSC 




3 

ORABIW 

DSC 




4 

ORACLN 

DSC 




5 

ORAARH 

DSC 




8 

MARTHA 

470 

MARTHA1 



8 

GEORGE 

46F 

0PS$GE0RGE 



9 

NINA 

4DC 

0PS$NINA 



11 

YVETTE 

480 

YVETTE 
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The Summary Display 


The summary display is used to monitor activity on the entire database. 
You can see total activity as well as activity during a set time interval. The 
Summary screen looks like: 


SYSTEM SUMMARY STATISTICS 10:17:18 


System 

Activity 

Counters 

Detached Process Errors 



Interval 

Cumulative 

Asynch Read Ahead 

0 

Log reads 

23489 

9968866 


Phy reads 

8829 

531679 

Before Image Compress 

- 

Log writes 

7834 

111011 


Phy writes 

736 

24518 

Before Image Write 

0 

DML commits 

329 

1168 


DML rollbacks 

101 

781 

Buffer Write 

0 

DDL commits 

65 

65 



DDL rollbacks 

10 

10 

Cleanup 

0 

Deadlocks 

0 

0 



Figure 12. The Summary Display 

Log reads the number of logical blocks read from the blocks found in the 
cache buffer pool. 

Phy reads the number of physical disk blocks read. 

Log writes the number of modifications to cache buffer blocks. 

Phy writes the number of physical disk blocks written. 

DML commits the number of data manipulation commits. 

DML rollbacks the number of data manipulation rollbacks. 

DDL commits the number of data dictionary commits. 

DDL rollbacks the number of data dictionary rollbacks. 

Deadlocks the number of deadlocks detected systemwide. 
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The Table Display 


The Table Display shows the name of each table cached in the tables 
cache. Note that not all tables currently being accessed appear - only those 
appear which are currently cached. It also shows the RBA (Relative Block 
Address) of the beginning of the table, the number of RcaD cursors and 
UPDate cursors for each user of each table. The RBAs can be displayed 
in decimal or hexadecimal numbers. By default the RBAs display as deci¬ 
mal; the hexadecimal display is useful to relate the RBAs in the display to 
the RBAs shown in the L(ocks) Display. 

Two dictionary table names, 'TABLES 7 and 'COLUMNS', are never 
cached but always appear in partition number one with RBAs of 9 and 
cluster ids of 1 and 2 respectively. 


ODS: TABLE ACCESS 10:27:54 

—Table-Identifier— Read Updt 


PID 

User Name 

Table Name 

Part 

RBA(hex) 

Cl us 

Curs 

Curs 

6 

0PS$B0B 

INV DATES 

1 

144a 

1 

1 

0 

7 

0PS$TED 

ADDRESSES 

1 

5ee3 

1 

4 

0 

8 

0PS$CAR0L 

DONATIONS 

1 

29df 

1 

20 

0 

8 

0PS$CAR0L 

not cached 

1 

2e0d 

1 

10 

7 

8 

0PS$CAR0L 

REMINDER 

1 

2b01 

1 

2 

2 

9 

0PS$ALICE 

PROJ ID 

1 

76b 

1 

1 

0 

10 

HARVEY 

WHOOPS 

1 

5222 

1 

1 

0 


Figure 13. The Table Display 

If the message "not cached" appears in the display, you might consider in¬ 
creasing the INIT.ORA parameter TABLES. 
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The User Display 


The U(ser) display can be invoked in several ways — by entering any of the 
following: 

U 

U <pid> 

U <first_pid> <last_pid> 

to display all currently active processes, only one, or a range of processes. 
The information varies slightly for the ORACLE background processes 
ARII, BIW, BWR, and CLN. 


Pid: 2 


USER 

STATUS DISPLAY 09:43:2 

User: 


Image: HSC000$DUA0:[ORACLE.V5]BWR.EXE;7 

Process 

Activity Counters 

Current Operation: none 


Interval 

Cumulative 

User cursors 0 

Log reads 

0 

0 

ORACLE cursors 0 

Phy reads 

0 

1 

Timeouts 600 

Log writes 

0 

0 

Deadlock count 0 

Phy writes 

98 

2779 


DML commits 

0 

0 

Queue wait: buffer write wait(BWW) 

DML rollbacks 

0 

0 


DDL commits 

0 

0 


DDL rollbacks 

0 

0 


Deadlocks 

0 

0 


DeadT 

0 

0 



Figure 14. The User Display for BWR 

Log reads the number of logical blocks read from the blocks found in the 
cache buffer pool. 

Phy reads the number of physical disk blocks read. 

Log writes the number of modifications to cache buffer blocks 
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Phy writes the number of physical disk blocks written. This value will al¬ 
ways be zero except for BWR. 

DML commits the number of data manipulation commits. 

DML rollbacks the number of data manipulation rollbacks. 

DDL commits the number of data dictionary commits. 

DDL rollbacks the number of data dictionary rollbacks. 

Deadlocks the number of deadlocks detected systemwide. 

Timeouts the number of posts received while a process was waiting for re¬ 
sources; a high number does not indicate a problem. 

DcadT a counter indicating the number of times a routine wanted to do 
deadlock detection while it was performing a rollback. Processes 
do not do deadlock detection during rollbacks, because they do 
not require additional enqueues. 1 herefore it is rare that Dead 1 
is incremented. However, if a process doesn't release a lock 
needed by the process doing a rollback, then Dead I could steadly 
increase. 

current operation the operation currently being performed by ORACLE 
for this process. It may differ from the statement invoked by the 
user; For example, a user doing a DROP TABLE might show a 
current operation of DELETE, because the rows must be deleted 
before dropping the table. 

User cursors the number of currently open cursors invoked explicitly by 
this process. 

ORACLE cursors the number of recursive cursors currently opened on 

behalf of this process by ORACLE. Recursive cursors are cursors 
which ORACLE opens for administering the database - for ex¬ 
ample, to update the data dictionary as tables or users are added 
or dropped. 

In the screen for CLN, if the value for "cleanups tried" does not equal the 

value for "cleanups succeeded" after a few cycles through the screen, you 

should perform an IOR SHUT or CLEAR and an IOR WARM. 
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Pid: 3 


USER 

STATUS DISPLAY 09:43:23 

User: 


Image: HSC000$DUA0:-ORACLE.V5]BIW.EXE;7 

Process 

Activity ( 

Counters 

Current Operation: none 


Interval 

Cumulative 

User cursors 0 

Log reads 

0 

0 

ORACLE cursors 0 

Phy reads 

0 

0 

Timeouts 686 

Log writes 

0 

0 

Deadlock count 0 

Phy writes 

0 

0 


DML commits 

0 

0 

Queue wait: before image wait(BIW) 

DML rollbacks 

0 

0 


DDL commits 

0 

0 


DDL rollbacks 

0 

0 


Deadlocks 

0 

0 



Figure 15. The User Display for RIW 


Pid: 4 



USER 

STATUS DISPLAY 09:43:37 

User: 


Image: 

HSC000$DUA0:-ORACLE.V5]CLN.EXE; 7 

Process 

Activity 1 

Counters 


Current Operation: none 


Interval 

Cumulative 

User cursors 0 

Log reads 

0 


0 

ORACLE cursors 0 

Phy reads 

0 


0 

Timeouts 16689 

Log writes 

0 


0 

Deadlock count 0 

Phy writes 

0 


0 


DML commits 

0 


0 

Queue wait: audit trail write(AUD) 

DML rollbacks 

0 


0 


DDL commits 

0 


0 


DDL rollbacks 

0 


0 

Cleanups tried: 2 succeeded: 2 

Deadlocks 

0 


0 

Last pid cleaned: 6 

DeadT 

0 


0 

Last error: 0 not active 


Figure 16. The User Display for CLN 
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CHAPTER 5. AFTER IMAGE JOURNALLING (AIJ) 


T his chapter describes how to enable journalling, which is a backup program 
for recovery in the event of media or system failure, and how to recover us¬ 
ing the AIJ files. Topics include requirements and options of enabling AIJ 
and a discussion of what occurs during recovery and possible errors. 


THE PURPOSE OF AFTER IMAGE JOURNALLING 


After Image Journalling is a DBA tool to provide for recovery of a database 
after a media failure, such as a head crash, on the disk drive(s) containing 
the database. Recovery is made possible by keeping a separate, parallel 
record (journal) of each block written to the database. The journal is a 
physical record of all changes to the database, and can be applied to a 
backup copy of the database to produce an exact copy of the lost database. 
Applying the journal is known as Toll forward" recovery. 


THE AFTER IMAGE JOURNAL 


The ORACLE After Image Journal consists of a set of sequential disk files 
written one at a time. Transactions are written to the file whenever (before) 
the corresponding block is written to the database. As the journal grows 
and a journal file is filled, the next file is opened for writing. If the data¬ 
base is heavily modified (due to many DMT statements), the After Image 
Journal can grow very large. This is because AIJ uses physical after imag¬ 
ing on an ORACLE block (2K) basis. If one byte changes, the whole 
block is written; thus the journal file may grow rapidly. Both data and 
index blocks are written, as well as special purpose blocks such as for 
storage allocation. 
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Each journal file is normally copied to tape after it is full to make room for 
further journalling. This can be done in background by the operator or a 
user-written procedure, so that ORACLE may run continuously. The 
journal may be a fixed set of preallocatcd files, or (on systems that support 
dynamic file allocation) a series of files of a specified size created bv 
ORACLE. 

Io guarantee that journal files arc applied in the same order in which they 
were written, a journal sequence number is written into the header of each 
journal file. A1J checks the header of each journal file before applying it. 
The journal sequence number is stored in the database and will start at 1 
when the IOR 1 command is given to initialize the database. Thereafter 
each subsequent journal file will use the next higher number. The se¬ 
quence number is never reset during normal operation. The only time the 
sequence may be altered is by the AIJ utility during a roll forward recovery 
operation. In this case, the sequence will resume after the last journal file 
applied by the AIJ program. 

If a system failure occurs, the after image journal is applied to a backup 
copy of the database which is known to be good. The application of the 
journal is done using the stand-alone AIJ utility before ORACLE is re¬ 
started. The AIJ program reads each file in the journal and updates the 
database with any blocks that were part of committed transactions. When 
the journal application is complete, and the before image file cleared, 
ORACLE may be restarted and database activity can resume. Any trans¬ 
actions that were outstanding at the time of the system failure will be ig¬ 
nored. 

The following sections discuss enabling AIJ so that journal files are written, 
and applying the files in the event of system failure. Potential messages and 
errors returned by AIJ are also described. 


PREREQUISITES FOR USING AIJ 


To use AIJ you must: 

• Periodically backup the database when it is known to be in a valid, 
consistent state. This backup should consist of image copies of all the 
database files and the before image file. Only backups such as this can 
be used as the base for subsequent journalling activity. 

• Discard any journal file generated prior to the backup. 

• Include the appropriate parameters in the INIT.ORA file. 
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To enable After Image Journal creation, do the following: 

1. Add the AFTER IMAGE parameter line in the INIT.ORA parameter 
file. 

2. You may optionally adjust the INIT.ORA parameter 
AI WARN PCNT. 

3. If using dynamic journal file creation, include the INI I ORA parameter 
FILESIZE. 

4. Back up the database (it must have been shut down cleanly; if not, warm 
start the database and shut it down before backing it up). 

5. Warm start ORACLE. 

Now, the writing of the journal begins with the first empty file in the 
journal file list. Thereafter a new journal file is opened whenever: 

• the current file is full, or 

• a journal write error occurs, or 

• ORACLE is restarted. 

As each journal file is opened, a message is sent to the operator console 
indicating the start of a new journal file. Journalling remains active until 
either ORACLE is restarted with journalling disabled, or a fatal error oc¬ 
curs in the writing of the journal, such as an out of space condition. 

Journal creation may be done in either of two modes. 

In the first mode, the journal is written to a fixed set of preallocated files. 
When each of these files has been filled, the operator (or a background 
process) must copy it to tape and refresh it using: 

AIJ INITIALIZE=fn 

The file may then be reused by the after image journal. ORACLE steps 
through the list of files specified by the AFTER IMAGE parameter line(s) 
in a circular pattern. That is, when the last file in the list is full, ORACLE 
tries to open the first one again. If that file has not yet been refreshed, 
ORACLE will try the next file until it finds one, or make the complete 
cycle unsuccessfully. In the latter case, journalling is aborted. 
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In the second mode, journal files are created dynamically by ORACLE. 
The size of each file is specified by the AI_FILE_SIZE parameter. 
ORACLE uses the directories or files specified in the journal file fist in 
which to create files in a monotonic sequence of filenames. This mode is 
not available on operating systems that do not support this type of file al¬ 
location (for example, IBM VM/CMS does not). 

1NIT.ORA Parameters Affecting Journalling 


Three 1NIT.ORA parameters relate to After Image Journalling: 

• AFTER IMAGE 

• AI FILE SIZE 

• AIWARNPCNT 

AFTERIMAGE 

This parameter must be present in INIT.ORA to enable journalling. It 
must list one or more journal file names. The list of journal files can be 
in several forms, the simplest being a single line of file names separated by 
commas. If the first character of the first file name is not alphanumeric, it 
is used (instead of comma) as the delimiter character for the following file 
names. Thus, file names may have embedded commas. Multiple 
AFTER IMAGE lines can be used if the list of file names exceeds one line, 
as long as the lines are subsequent. The parameter strings on each 
AFTER IMAGE line are concatenated, into a single string after removing 
leading and trailing whitespace. 

I'he following examples illustrate several ways of specifying the same list 
of journal files: 


I: 

AFTER_IMAGE 

FILENAME1,FILENAME2,FILENAME3 

II: 

AFTER_IMAGE 

\FILENAME1XFILENAME2XFILENAME3 

III: 

AFTER IMAGE 

\FILENAME1\FILE 


AFTER_IMAGE 

NAME2XFILENAME3 

IV: 

AFTER IMAGE 

,FILENAME1 


AFTER IMAGE 

,FILENAME2 


AFTER IMAGE 

,FILENAME3 
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AI FILE SIZE 

This parameter can only be used on operating systems which support dy¬ 
namic file allocation. It causes journal files to be created by ORACLE and 
sets the size (in ORACLE blocks) of the journal files. The following ex¬ 
ample sets the size for dynamically created journal files to be 20 ORACLE 
blocks. 

AI_FILE_SIZE 20 

Journal files are given unique names to avoid conflict; the name is derived 
from the journal sequence number and name given in the 
AETERJMAGE parameter line. Unique names are generated by over¬ 
riding the file name portion (not the directory) of each journal file spec with 
a name derived from the internal journal sequence number. The journal 
file names are in the form SQNwinnwi.AU, where nnnnnn is a 6 digit 
number between 000001 and 999999. ORACLE creates these dynamic files 
in the directory(s) specified by the AFT ER IMAGE parameter line(s). 
Directories are used in the order they appear in the AFTER IMAGE lines. 


AI WARNJPCNT 


This parameter sets the point at which ORACLE sends a message to the 
operator console indicating that the current journal file is getting full. The 
number given is the percentage of space used, as in: 

AI_WARN_PCNT 80 

In this case a message would be sent to the operator console when any 
journal file became 80% full. 


APPLYING THE JOURNAL FILES (INVOKING AIJ) 


When After Image Journalling has been enabled to write journal files, the 
AIJ utility can be used to update the backup copy of the database which 
reflects the database when journalling began. AIJ must not be run unless 
ORACLE is shut down. 

The journal files are processed in two passes. 1 he first pass collects sta¬ 
tistics, and builds a list of transactions that were never committed in order 
to eliminate them from the journal application. 

Pass two modifies the database, applying all blocks that arc not part of the 
incomplete transactions found in pass one. 
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The operation of AIJ may be modified by several command line parame¬ 
ters. Some parameters can be passed on the command line, some read 
from the IOR parameter file, and some answered at the terminal. 

The AIJ Command and Parameters 


The syntax for AIJ is: 

AIJ [ parameter^ ] [ parameter ] [ parameter3 ] 

All parameters are optional and the delimiter is a space, not a comma. 
Descriptions of the parameters for the AIJ command follow. 

DATABASE = filcspcc Name of the primary database file. If not specified, 
AIJ looks in the IOR parameter file for the matching parameter 
(see PFILE). 

DEBUG = {1|2|3) Used only for debugging, or reporting detailed statistics, 
this parameter controls the amount of information output to the 
terminal about the journal blocks being read. 

• A 1 causes only commits and rollbacks to be displayed. 

• A 2 causes a line for each journal block. 

• A 3 causes AIJ to continue past certain |probably] fatal errors. 

I he DEBUG parameter is normally omitted. 

FIRSTJSQN = minium Journal sequence number of the first journal file to 
apply (a number between 1 and 999999 inclusive). It must iden¬ 
tify the first journal file created after the database backup oc¬ 
curred. If not specified, AIJ uses the sequence number found in 
the database. This parameter should normally be omitted; if in¬ 
correctly specified it may damage the database. 

INITIALIZE = filcspcc This option is used to refresh an AIJ journal file 
which has been filled and copied to tape. This option initializes 
the specified file so that it may be reused by AIJ. 

NO_ APPLY The presence of this parameter inhibits the second pass of 
AIJ, when the journal is actually applied. It can be used if you 
wish to simply gather statistics on the journal and database ac¬ 
tivity. 
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PFILE = filcspec Name of alternate lOR parameter file in which to search 
for the DATABASE parameters (ignored if both are specified on 
the command line). If not specified, the default is INIT.ORA. 

UNTIL = timespec Date and time up to which to apply the journal. All 
transactions committed after this time are ignored. The format 
of the time specification is: 

mm/dd/yy-hh:mm:ss.mmm 
! ! ! ! ! !! 

! ! ! ! ! !+- millisec (0-999) 

! i ! ! ! +-seconds (0-59) 

! ! ! ! +-minutes (0-59) 

! ! ! +-hours (0-23) 

! ! +-year (0-99) 

! +-day (0-31) 

+-month (0-12) 


What Occurs during Pass One and Pass Two of A1J 


After checking the A1J parameters, AIJ opens the primary database file 
and displays the names of the database extents, including the primary da¬ 
tabase file (this does not happen if NOAPPLY was specified on the 
command line). 

Next, AIJ performs pass one on the journal files, requesting the name of 
each successive journal file and scanning each file for uncommitted 
transactions. After the last file has been read, you'll see a file name prompt 
to which you should enter an empty line to end pass one. At the end of 
pass one, AIJ displays a summary of the data found in the journal, in¬ 
cluding a list of transactions that were never completed. Each "open" 
transaction is displayed as a single line consisting of the transaction id (tid), 
and the journal block number of the first and last block seen for the 
transaction. The journal block number is described by the journal se¬ 
quence number and the block number within that file. 

Then AIJ normally proceeds with pass two. It does not continue if there 
were no completed transactions, or the NO APPLY option was specified 
on the command line. At the beginning of pass two, all database extents 
are opened. Then the entire journal is read again, using the same filenames 
given in pass one, and the database is updated with the journal blocks 
containing committed transactions. Pass two may take some time. As in 
pass one, the name of each journal file is displayed when processing begins 
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on the file. And when processing of the file is complete, AIJ displays the 
number of ORACLE blocks in the file which were actually applied. 

After all journal files have been processed, the journal sequence number is 
updated in the database. Finally, AIJ closes the database extent files and 
terminates with a completion message. 


MESSAGES RETURNED TO THE OPERATOR'S CONSOLE 


The following messages may be sent to the operator's console while 
ORACLE and journalling are running. 

ORACLE error 1 n' identifying AI journal 'file' - IOR aborted 

ORACLE could not find the indicated journal files during IOR. Unless 
using dynamic file creation, all files specified must be accessible during IOR 
as a check. 


ORACLE can't open any after image journal file. - IOR aborted 


ORACLE could not open any of the specified journal files. They arc all 
either full, not properly initialized, or write-protected. IOR is aborted. 


ORACLE can't build AI journal name from 'filespec' 


ORACLE could not parse out the device or directory portion of the indi¬ 
cated file specification in the list of journal files (only if dynamically creat¬ 
ing and allocating journal files). 


ORACLE error 'errno' 
ORACLE error 'errno' 
ORACLE error 'errno' 


identifying AI journal 'filespec' 
opening AI journal 'filespec' 
writing AI journal 'filespec' 


ORACLE could not locate, open, or read the header of the indicated 
journal file. 
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ORACLE starting after image journal file #' jseq' - 'filespec' 

ORACLE could not write the header of the indicated journal fde. 

ORACLE warning: AI journal 'filespec' is '#' percent full. 

The indicated journal file has reached the AI_WARN_PCNr full point. 

ORACLE error 'errno' writing block #'blockno' to AI journal 'filespec' 

ORACLE could not write a block to the indicated journal file, although 
the journal had been previously written to. 

Unable to open any after image journal. Journalling aborted. 

ORACLE could not find or open any of the journal files specified in the 
lOR parameter file. 

Unable to write any after image journal. Journalling aborted. 

ORACLE could not write to any of the empty journal files. Journalling 
is aborted until the next IOR. 


A1J ERROR MESSAGES 


The AIJ utility terminates if it encounters any of the following errors: 

Can't open database file 'filespec' 

One of the database extent files docs not exist as named, is in use, or is 
write protected. 

Can't open parameter file 'filespec' 

The IOR parameter file cannot be opened for read access. If the I’FILE 
parameter is not specified, AIJ assumes INI LORA 
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Cannot identify database file 'fi1espec' 

Cannot open database file 'filespec' 

I he primary database does not exist as named, or is in use, or is write 
protected. 


Database file specification not found 

The DATABASE parameter was not given on the command line, or in the 
10R parameter file. 


Error parsing UNTIL spec starting at 'datespec' 

The value given for the UNTIL parameter was not in a valid format. The 
problem starts near the indicated position in the parameter value. 


Error reading block 'blockno' 

An error occured while reading block 'blockno' of the current journal file 
(in ORACLE blocks) 


Invalid parameter 'paramname 1 

A parameter, 'parmname', was specified on the command line that is not 
one of the legal parameters. 


No transactions to apply. 

No completed transactions were found in the journal. Thus, there is 
nothing to roll forward. 


ORACLE error # 'errno' reading block 'blockno' in file 'filespec' 

An error occurred trying to read the first part of the primary database file, 
to look up the names of the database extents, or the journal sequence 
number from the database. 
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ORACLE error # 


Run with DEBUG 


'errno' writing block 'blockno' to file 'filespec' 

An error occurred trying to update block blockno of database extent 
file 'filespec'. 

> 2 to continue. 

A journal corruption error was found that invalidates the recoverability of 
the database. A1J may be forced to continue by setting the DEBUG pa¬ 
rameter to 3, although this is not likely to be useful. 
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CHAPTER 6. MODIFYING DISPLAY TERMINALS (THE CRT UTILITY) 


WHAT IS THE CRT UTILITY? 


The CRT program is used to create or modify terminal definitions used by 
some ORACLE programs. Terminal definitions are used to: 

• match a set of functions required by an ORACLE program to the ter¬ 
minal keys used for that function. 

• define the use of CRT display characteristics, such as reverse video, bold 
or highlighting, and underlining, for use in full-screen products. 

The use of terminal dcfmitions for various display devices offered by vari¬ 
ous hardware vendors means that ORACLE products are device inde¬ 
pendent ; that is, an ORACLE program will run similarly regardless of 
which CRT device is currently being used. 

You can think of terminal definitions as storing the following relationships: 


ORACLE program 

Terminal type 

Terminal key : 

Program function 


For example: 



SQL*Forms IAP 
SQL*Forms IAP 

: VT100 

: IBM3270 

: numeric 7 : 

: ENTER : 

Next Field 

Next Field 


Terminal-specific information is stored in several database tables. The 
CRT utility uses these tables to compile source information into fries which 
other programs require during their operation. I hese files arc called .CR I 
files (if a terminal type has a corresponding .CRT file, then it has a ter¬ 
minal definition"'.) 

Oracle Corporation provides many standard terminal definitions for differ^ 
ent terminals and ORACLE programs (see “Appendix F. Terminal Defi- 
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nitions Provided by Oracle Corporation” on page 239), so you may never 
require anything other than the default terminal definition. However, if 
you want to create new terminal definitions or modify existing ones, then 
the CRT utility is available specifically for that purpose. 


WHICH ORACLE PROGRAMS USE CRT? 


The following full-screen ORACLE products require a CRT file for oper¬ 
ation: 

• SQL+Forms (in particular, IAP and IAD) 

• SQL*Calc 

• SQL*Menu 

REQUIREMENTS OF TERMINALS SUPPORTED BY CRT 

CR T supports two types of display devices: 

synchronous devices, such as IBM 3270s, which transmit and receive data 
a field or a screen at a time (also known as block mode devices). 

asynchronous devices, such as DEC VTlOOs, which transmit and receive 
data a character at a time. 

Asynchronous terminals must be able to: 

• transmit each character or field as it is entered 

• use the character set native to the operating system (ASCII or EBCDIC) 

• move the cursor non-destructivcly one position left 

• move the cursor non-destructively one position right 

• position the cursor to a given column and row (sec "Specifying Cursor 
Coordinates” on page 86) 

• process data as fast as the baud rate setting permits data to be received 
(or have a flow control protocol such as X-ON/X-OFF) 
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• clear entire screen when cursor is placed in upper left-hand comer. 

SQL*Forms can take advantage of the following terminal characteristics 
on either synchronous or asynchronous terminals: 

• split screen scrolling (the ability to scroll data in a range of lines without 
affecting other parts of the screen). 

• semigraphic characters for displaying unbroken lines and boxes. 

• underlining and reverse video or equivalent display techniques. Charac¬ 
teristics must be implemented so that: 

- Once a characteristic is set, the device will display incoming data with 
that characteristic until it is reset. 

- Turning a characteristic on or off does not move the cursor. 

- Turning a characteristic on or off does not "mark" a certain portion 
of the display as having that characteristic. 


DEFAULT DEFINITIONS 


Every ORACLE distribution tape contains a default terminal definition, 
usually identified as DEFAULT.CRT. This file sets up key functions for 
the terminal type commonly used by the operating system; for example, it 
defines key mappings for IBM 3270s or for DEC VI 100s. 

SQL*Forms always assumes you are using the default terminal; if you want 
to use a non-default CRT, you must invoke the program and terminal 
specifically, as in invoking IAP using the -t option: 

IAG -t VT100 

SQL + Calc and SQL + Menu may be invoked cither way: assuming the de¬ 
fault or specifying a non-default device. 
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DATABASE TABLES USED BY CRT 


ORACLE user SYSTEM owns several tables in the database which are 
used by the CRT utility. These tables are summarized in Figure 17 and 
they arc described in detail in following sections. 


TABLE 

PURPOSE 

CRT 

Describe several hardware characteristics of terminals. 

CRTBOX 

Associate graphics characters for drawing boxes for a terminal. 

CR T PRODUCTS 

Assign codes to ORACLE products requiring use of CRT definitions. 

crttype 

Assign codes to CRT devices, and note whether device is 
synchronous or asynchronous. 

ESC 

Map ORACLE Product to Terminal Type to Key to Function. 

FUNCTIONS 

Assign two-letter codes to ORACLE product screen functions. 

GOTOLC 

1 ranslate linc/column position to cursor coordinates 

OR: translate cursor coordinates into coordinate codes for certain types 
of display devices for which coordinate codes cannot be computed. 

Figure 17. Summary of CRT Tables 


These tables are usually created as a last step of installation. On many 
operating systems a file named CRTINS is used to log on to SQL+Plus as 
ORACLE user SYSTEM, and create and load the tables. Refer to the 
Installation and User's Guide for your operating system for a description 
of installing these tables. 

Note that CRT INS does not give access to the CR T tables to any user 
other than SYS TEM, so if other ORACLE users require access (INSERT 
or UPDATE) then SYSTEM must explicitly grant that access. 


Table SYSTEM.CRT 


Each record of SYS TEM.CR T describes the characteristics of a particular 
type of terminal device. The entries in this table for a given terminal de- 
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termine how the full-screen products (SQL + Forms, SQL + Menu, 
SQL+Calc) will appear - how they make use of terminal charactenstics like 
bold or highlighting, or reverse video. For terminal specific information 
on how to update this table or insert new rows for a new terminal, you 
will probably require the programmer's reference or escape sequence doc¬ 
umentation for the terminal of interest. 

NOTE: The table SYSTEM.CRT is independent of ORACLE product. 
Because there is not a column for "product , characteristics are constant 
during ORACLE use for any given terminal definition. 

Descriptions of the table's columns follow. It is assumed that none of the 
commands or escape sequences entered (for example, the sequence for 
CLEARSCREEN or for PROTON) change the current cursor position. 

NAME Name of device type, used as the root of the .CRT file name. 

The name must conform to the rules for filenames in your O/S. 

TYPE One of two codes indicating device type: 

• CHAR indicates asynchronous device (character) 

• 3270 indicates synchronous device (block mode) 

OFFSET A code used to obtain cursor coordinates. Usually the numeric 
value to be added to a line or column number to convert it to a 
single character. This value is usually 31 or \037. However, if 0, 
indicates that device expects cursor coordinates to be sent as 
character strings. 

BASE Number of the first line of the terminal; usually either 1 or 0. 

LC TABLE The name assigned to this terminal in table GOTOJX. If 
GOTOLC needs no corresponding row, then this value is null. 

LINES Number of lines on this terminal's screen. 

COLUMNS Number of characters across each line of this terminal. 

MSGL Line number of the message line. 

MODE Line number of the status line. 

CLEARSCREEN Command used to clear terminal's screen when cursor 
is in upper left comer. 

BACKSPACE Command to move cursor left one position. This should 
be a non-destructive backspace character. For most asynchro¬ 
nous devices the value is \008. 
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FORESPACE Command to move cursor right one position. This should 
be a non-destructive forward space character. A blank is not ac¬ 
ceptable. 

GOTO CL Command to move cursor to a specified line/column position. 
Use \y for coordinate of line, and \x for coordinate of column. 
(The sequences \y and \x can only be used in this column; they 
have no meaning in other columns.) See — Heading id " un¬ 
known — for additional information about specifying cursor co¬ 
ordinates. 

CLEARLINE Command to clear one entire line regardless of the cursor's 
current position. 

1SET , C ;? 1 m A mand to initia,ize terminal for use; sent as first command for 
ORACLE utilities using CRT. For example, SQLTorms might 
change DEiC terminal SET UP characteristics (and re-set them 
using TRSET). 

1 RSET Command to de-initialize terminal after use; sent as final com¬ 
mand command for ORACLE utilities using CRT. For example 
SQL+Forms would reset DEC terminal SETUP characteristics 
(which were set using TSET). 

A'lTI Command to turn on video attribute 1 (usually reverse video). 

Used by SQL*Forms for enterable fields ; not used by SQL+Calc. 
Also note that the screen-painter, IAD, only uses ATT 1. 

Al l 2 Command to turn on video attribute 2 (usually underlining). 

Used by SQL*Forms for values in the HELP screen; not used 
by SQL*Calc. 

ATI1_2 Command to turn on video attributes 1 and 2. Used by 
SQI ,* Forms for the message line-, not used by SQL*Calc. 

AITOFF This is the escape sequence which will cause characters to be 
written to look the same way as the screen looks after a "clear 
screen." 

WINDOW Command to create a scrolling region of a subset of line on the 
display. Use \t and \b for coordinates of top and bottom lines. 

(1 he sequences \t and \b can only be used in this column; they 
have no meaning in other columns.) See - Heading id " un¬ 
known -- for additional information about specifying cursor co¬ 
ordinates. 

SCRUP Command to scroll scrolling region up one line. 

SCRDN Command to scroll scrolling region down one line. 
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GRAPHON Command to make display device interpret input as graphic 
data rather than character data. If the device has no graphics 
feature, this field should be null. 

GRAPHOFF Command to make display device interpret input as charac¬ 
ter data rather than graphics data. If the device has no graphics 
feature, this field should be null. 

PROTON Command to turn on screen protection. 

PROTOFF Command to turn off screen protection. 

CLEAREOL Command to clear from current cursor position to the end 
of line. 

CURSORUP Command to move cursor up one position. 

CURSORDOWN Command to move cursor down one position. 

TOP2X T his command applies to the line where the cursor is currently 
located, and enables the display of characters at twice their normal 
size, both horizontally and vertically. TOP2X specifies characters 
be displayed double-width and as the top half of a double-height 
character. It should be used with BOTTOM2X. 

BOTTOM2X This command applies to the line where the cursor is cur¬ 
rently located, and enables the display of characters at twice their 
normal size, both horizontally and vertically. BOTTOM2X 
specifies characters be displayed double-width and as the bottom 
half of a double-height character. It should be used with TOP2X. 

ATT3 Command to turn on an arbitrary screen characteristic, such as 
bold or highlighting. Used by SQL*Forms, not used by 
SQL + Calc. 

ATT1_3 Command to turn on an arbitrary screen characteristic, such as 
bold or highlighting. Used by SQL + Forms, not used by 
SQL + Calc. 

ATT2_3 Command to turn on an arbitrary screen characteristic, such as 
bold or highlighting. Used by SQL*Forms, not used by 
SQL + Calc. 

ATT123 Command to turn on an arbitrary screen characteristic, such 
as bold or highlighting. Used by SQL + Forms, not used by 
SQL*Calc. 

ATT_B()LD Command to turn on bold or highlighting. Used by 
SQL+Calc, not used by SQL+Forms. 
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AI I_FLASH Command sequence to turn on blinking display. Used bv 
SQL+Calc, not used by SQL+Forms. 

A I r_REVRS Command sequence to turn on reverse video. Used by 
SQL+Calc, not used by SQL+Forms. 

A IT_UNDER Command sequence to turn on underlining. Used by 
SQL+Calc, not used by SQL+Forms. 

Note the following for the various attribute columns (such as ATT1 or 


• All A'I 1 x settings except for ATTOFF are sent to the terminal imme¬ 
diately after the ATTOFF escape sequence is sent. Thus, when entering 
the escape sequence for terminal attributes, you should enter only the 
sequences required to enable the attribute given that all attributes were 
previously set off. (You need not turn any off, just turn on the one(sj 
of interest.) 

I wo or more of the reverse , flash , ''underline", and "bold" escape se¬ 
quences may be sent to the terminal together, immediately after an 
A T TOFF escape sequence. 

• I here is no interaction or precedence between named and numbered at¬ 
tributes. 


• Each AT I x setting is actually used to enable an arbitrary screen charac¬ 
teristic, not necessarily a combination of two other characteristics. For 
example, ATT23 need not necessarily equal a combination of ATT2 
and ATT3. 

• The use of the attribute escape sequences is different for each ORACLE 
product using CRT. [At press time] SQL+Forms uses the numbered 
attributes only (such as ATTJ), while SQL+Calc uses the named attri¬ 
butes only (such as ATT BOLD). 

• I hough this manual indicates how ORACLE products currently use 
which attributes, that usage is likely to change over time. If you have 
additional questions, you should check release notes for new information 
or call Oracle Customer Support. 


Table SYSTEM.CRTBOX 


This table contains one row for each supported terminal, with several col¬ 
umns. Each column indicates the character used by that terminal for dis¬ 
playing or printing certain graphics characters. All columns are defined as 
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one character, except the CRTNAME column, hollowing are descriptions 
of the columns of table SYSTEM.CRTBOX. 

CRTNAME Name of terminal device, as found in table CRT. 

CMODE Graphics mode indicator. If set to Y for "Yes", then IAD will 
use these characters for output to the screen or to print files. 

BOX_BV Vertical line for CRT display of box. 

BOX BH Horizontal line for CRT display of box. 

BOXCUL Upper left corner for CRT display of box. 

BOX_CUR Upper right corner for CRT display of box. 

BOX_CBL Lower left comer for CRT display of box. 

BOX_CBR Lower right comer for CRT display of box. 

BOX_TL Left sided T for CRT display of box. 

BOX TR Right sided T for CRT display of box. 

BOXTU Upright T for CRT display of box. 

B()X_TB Inverted T for CRT display of box. 

B()X_X Cross for CRT display of box. 

PRT BV Vertical line for output to print file. 

PRTBH Horizontal line for output to print file. 

PRT CUL Upper left corner for output to print file. 

PRT_CUR Upper right corner for output to print file. 

PRT_CBL Lower left corner for output to print file. 

PRT_CBR Lower right corner for output to print file. 

PRT TL Left sided T for output to print file. 

PRT_TR Right sided T for output to print file. 

PRTTU Upright T for output to print file. 

PRTTB Inverted T for output to print file. 

PRT X Cross for output to print file. 
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Table SYSTEM.CRT PRODUCTS 


This table assigns a product code to ORACLE products using CRT dis- 
play devices. The columns descriptions follow: 

PR()D_CODE A code up to six characters assigned to the product. This 
code is used in tables ESC and FUNCTIONS. 

I ROD_NAME I he name of the product using CRT devices. 

The table contains entries for SQL+Forms, SQL + Calc, and SQL+Mcnu. 

I hough SQL+Calc uses the CRT utility, it does not use it to define key 
functions, and so there is no entry for Easy+SQL in CRT PRODUCT. 

Table SYSTEM.CRT TYPE 


I his table indicates whether a terminal is an asynchronous or synchronous 
device. You normally will not need to alter this table; it is simply used to 
validate entries in the CRT table. The column descriptions follow: 

NUM An integer code as follows: 

• 1 an asynchronous device. 

• 2 a non-3270 synchronous device. 

• 3 a 3270 type synchronous device. 

TYPE A two-character code used to identify the type of device. 
DESCRIP TION A text description of the type of device. 

This table looks like: 

SELECT * FROM CRT_TYPE: 

NUM TYPE DESCRIPTION 

1 CHAR Character oriented terminal 

2 BLOCK Block Mode with hidden attributes 

3 3270 3270 look alike 
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Table SYSTEM.ESC 


This table has many rows for each terminal, each row describing a corre¬ 
spondence of ORACLE product to terminal name to terminal key to pro¬ 
gram function. Column descriptions follow: 

PROD_CODE Code assigned to ORACLE utility using CRT. 

NAME Code for terminal, corresponding to code used in CRT. 

FUNC Code for terminal function, corresponding to code used in 
FUNCTIONS. 

ESCSEQ Character sequence generated by the terminal when this function 
key is pressed. The sequence is in the form \nnn where tinn is 
three octal digits. To avoid conflict with ordinary data entry this 
sequence must begin with a character not generated by any typing 
key. Note that you must enter a displayable representation of 
nonprintable characters. For example, on a VT100 control-Z is 
represented as \032 and escape is represented as \e. 

COMMENTS Description of function key, used in the Help screen for 
users. 

Table SYSTEM.FUNCTIONS 


This table lists ORACLE full-screen products, such as SQL+Forms and 
SQL+Menu, along with the screen functions they require, and assigns 
function codes to each function. This table should not be altered, or 
SQL+Forms will behave unpredictably. The columns descriptions follow: 

PROD CODE A three-character code assigned to full-screen ORACLE 
utilities which use the CRT utility. This code should correspond 
to one in table CRT_PRODUCTS. 

FUNCN An integer assigned to the function/product combination. 

FUNC A two-character code assigned to the function. This code will be 
used in the table ESC. 

FNAME A description of the function, such as "move cursor right". 

See “Appendix E. Terminal Function Codes for Using CRT” on page 235 
for a listing of function codes and their descriptions for the products 
SQL+Forms (IAP) and SQL+Menu. 
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Table SYSTEM.GOTO LC 


Certain terminals require the table SYSTEM.GOTOLC for translating 
line and column addresses of the cursor on the screen to cursor coordinates 
for use by ORACLE. Not all terminal types require the use of this table 
- only those whose line or column addresses are not a continuous as¬ 
cending sequence of numbers (and so cannot be calculated as line or col¬ 
umn number plus BASE plus OEESET). 

If a CRT s line coordinates cannot be calculated, GOTO LC should con¬ 
tain a set of entries translating line numbers to line coordinates, one [entry] 
per line. Similarly, if a CR T's column coordinates cannot be calculated, 
GOTO LC should contain a set of entries translating column numbers to 
column coordinates, one entry per column. If neither the line or column 
coordinates can be calculated, GOTO LC should contain both sets of en¬ 
tries. 

Column descriptions follow: 

NAME The name of the CRT, corresponding to the NAME in table 
CRT. 

IYPE I ype of coordinate described by this row. Meaningful values are: 

• L Line coordinate 

• C Column coordinate 

VALUE The line or column number whose cursor coordinate this row 
defines. 

ESCSEQ The character sequence that is this line or column's cursor co¬ 
ordinate. 
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ADDING NEW TERMINAL DEFINITIONS 


To add a new terminal definition, you can use the CRT form to fill in the 
necessary information in a screen, or you can use SQL + Plus to insert rows 
into the CRT tables. 


With the CRT Form 


To add a new terminal definition using the CRT screen, follow these steps: 

1. If the file CRT.FRM exists, you can enter: 

IAP CRT 

If the FRM version has not yet been created, you can create it by run¬ 
ning: 

IAG CRT -T 

Then run the first command to bring the CR T screen up. The CRT 
form consists of 2 pages as shown in Figure 18 on page 84 and 
Figure 19 on page 85. 

2. Fill in the blanks in the CRT screen to get the terminal attributes and 
key mappings you desire. 

3. Leave the screen, and generate the CRT file by running the CR l pro¬ 
gram (see “Running the CRT Program” on page 87) Make sure that on 
the command line you specify the name of the CRT which you used on 
page 1 of the CRT form. 
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Crt Name: 


Type: 


Columns: _ Lines: _ Mode Line: 


Message Line: 


Base: 


Terminal Setup: 
Graphics On: 
Protect On: 
2X Top: 


Term Reset 
Graphics Off 
Protect Off 
2X Bottom 


c 

learscreen: 

Clear Line: 


Clear to EOL: 

Create window: 

Scroll Up: 


Sc ro 11 Down • 


C-L Offset: _ 

Goto C-L: 


i L/v TT 1 1 • 

C-L Map: 

Cursor Left: 

Right: 

Up: 

Down: 

Video Bold: 

Flash: 

Revrs: 

Under: 

Attribs Off: 

1: 

2: 

3* 


1+2+3: 

1+2: 

2+3: 

1+3" 


Figure 18. The CRT Screen: Page 1 
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Graphics (Y/N): _ Screen Printer 

Vertical line: _ _ 

Horizontal line: _ _ 

Crt Name Upper left corner: 

_ Upper right corner: _ _ 

Lower left corner: _ _ 

Lower right corner: _ _ 

Left-side T: _ 

Right-side T: _ 

Upright T: _ 

Inverted T: _ _ 

Cross (+): _ _ 

Prod Fn 

Code Cd Function Description Escape Sequence Comments 


Figure 19. The CRT Screen: Page 2 

With SQL*Plus 


To add a new terminal definition with SQL*Plus, follow these steps: 

1. Obtain access to the set of tables shown in Figure 17 on page 74. (These 
tables are typically owned by the DBA user SYSTEM.) 

2. Insert a row in table CRT to define the device's general properties. 

3. Insert a number of rows in table ESC to assign keyboard keys to 
ORACLE product functions. 

4. If the CRT's device cursor positioning command uses coordinate codes 
that cannot be computed, insert a number of rows in table GOTO LC. 

5. Run CRT to create a CRT file for the device. 
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Specifying Cursor Coordinates 


The row and column positions must each be expressible either as a char¬ 
acter string or as a single character whose binary value is equal to the co¬ 
ordinate value plus a constant. If a display device's cursor coordinates 

C ex P resse d as line or column numbers plus a constant, the table 
GOTO_LC must be used to translate line and column numbers into cursor 
coordinates on a value-by-value basis. 

In the table GO I ()_LC the term cursor coordinate has a precise meaning: 
it refers to the number which must be sent to the display device as part of 
a command to position the cursor to a particular line and/or column. The 
number may be sent as an ASCII string or in binary form (as a single byte), 
but it is not necessarily the same as the number of the line or column itself* 
or even the number of the line or column plus a constant. 

The V and '\y' in the "goto" escape sequence, and the '\t' and '\b' in the 
scrolling region" escape sequence, are replaced by one or more characters 
which represent a line or column position. The characters which represent 
the line or column position are determined by the following rules: 

1* If the base value is 0, then lines and columns are numbered starting from 
0, or if the base value is 1, then lines and columns are numbered starting 
from 1. An exception is that lines and columns are always numbered 
starting from 1 if a translation table is specified. Base values other than 
0 or 1 are not allowed. 

2. If a translation table is specified, then use the string which corresponds 
to the line or column position. Line and column are always relative to 
1 for this purpose (i.e. the top line is line 1, and the first column is col¬ 
umn 1), regardless of the "base" field in the CRT table. T he line and 
column translation tables must be exactly the same size as the size of the 
terminal being defined. Also, the translation table is the onJy means by 
which columns and lines can be translated differently from each other. 

3. Otherwise, if an offset value is specified, then the character string which 
represents the line or column position is a single character whose BI¬ 
NARY value is the offset value plus the line or column number. For 
example, the character which represents the top line or the leftmost col¬ 
umn has a binary value equal to the offset value if the base value is 0. 
The offset value cannot be negative. Also, the offset value cannot be 0 
if the base value is also 0. 

4. If no offset value or translation table is specified, then the character string 
used is the DECIMAL representation of the line or column position. 

For example, the top line is represented by the string 'O' if the base value 
is 0, or 'I' if the base value is 1. 
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MODIFYING EXISTING TERMINAL DEFINITIONS 


To modify an existing definition, you can either: 

• Use the SQL*Forms application CRT to update data for the terminal 
and product functions to be changed. Or: 

• Use SQL*Plus to update the same entries in the tables ESC. 


RUNNING THE CRT PROGRAM 


After you have entered the new data for your terminal definition into the 
database tables, you can run the CRT program to generate the .CRT file 
for the new terminal. The syntax for CRT is shown in Figure 20. 


CRT <crtname> [user/id] [-d?] 


Figure 20. Syntax for CRT Command 

The ertname specified in the command line must correspond to the name 
of the ert in the tables CRT, ESC, and CRTBOX. If the d option is not 
used, the output file is named ertname. CRT; if the d option is used, then 
the .CRT file is named DEFAULT.CRT. Where the newly created CRT 
file is written is operating system dependent; see the Installation and User's 
Guide for your operating system. 

T he user invoking CRT must have access to all the tables shown in 
Figure 17 on page 74. 
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INSTALLING/INITIALIZING CRT (DBA RESPONSIBILITIES) 


Regarding using CRT and terminal definitions, the DBA is responsible for 

the following: 

• running the file CRTINS to create and load the CR T tables in the da- 
tabase 

• specifying the terminal whose definition will be the default (by answering 
a prompt which appears at the end of CRTINS) 

• granting access to the set of CRT tables to applications designers who 
may want to modify terminal definitions 

• making sure that applications users know the keyboard assignments for 
the ORACLE applications they are using. 


HINTS ON USING CRT 


Version 2 of SQL+Forms supports 132 character displays. The form 
should be defined using a CR I file which supports 132 columns and run 
with a file supporting 132 columns. The two CRT files need not be the 
same in other respects. 
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PART III: ORACLE DATABASE STRUCTURE 


This part describes in detail how data is stored in the database. The first 
chapter describes the data dictionary which is present in all databases, and 
is a central reference point for finding data. 1’he next chapter describes data 
storage, beginning with the largest unit or biggest picture - the database 
— and working down in detail to the finest unit or most detail — datatypes. 
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CHAPTER 7. THE ORACLE DATA DICTIONARY 


This chapter describes the creation and purpose of the tables in the database 
referred to as the data dictionary. A listing of the tables' columns is found 
in Appendix B. 

One of the most important parts of the ORACLE RDBMS is its data 
dictionary. The data dictionary is a set of tables, automatically created and 
updated, which records the names and descriptions of users, tables and 
views, and information about user privileges and data storage. In other 
words, it is a valuable source of database information. Every user will use 
the data dictionary for reference. The DBA will use the data dictionary to 
monitor use of the ORACLE RDBMS and to assist users with their ap¬ 
plications. Finally, the ORACLE RDBMS itself uses the data dictionary 
to record, verify, and conduct ongoing work. 


WHAT IS THE DATA DICTIONARY? 


The data dictionary is a set of tables and views, automatically generated and 
updated by ORACLE, to be used as a reference guide to the data, its 
storage, and users. For example, the data dictionary will tell you: 

• the ORACLE ids of ORACLE users 

• names of database objects owned by users (tables, space definitions, 
views, indexes, clusters, synonyms) 

• how much space has been allocated for and used by the objects 

• rights and privileges which have been granted. 

The data dictionary is normally created when the ORACLE system is in¬ 
stalled by using SQL^Plus to run the file CATALOG.ORA. Thereafter, 
it is always available as a reference for any user, whether or not that user 
has created any tables. 
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TNAME 


Reference 

Date 

AUDIT_ACCESS 

AUDIT_ACTIONS 

AUDIT_CONNECT 

AUDIT_DBA 

AUDIT_EXISTS 

AUDIT_TRAIL 

CATALOG 

CLUSTERS 

CLUSTERCOLUMNS 

COL 

COLUMNS 

DBLINKS 

DEFAULT_AUDIT 

DTAB 

EXTENTS 

INDEXES 

PARTITIONS 

PRIVATESYN 

PUBLICSYN 

SESSIONS 

SPACES 

STORAGE 

SYNONYMS 

SYSAUDIT_TRAIL 

SYSCATALOG 

SYSCOLAUTH 

SYSCOLUMNS 

SYSDBLINKS 

SYSEXTENTS 

SYSINDEXES 


To see the initial list of dictionary views available to all ORACLE users, 
enter the SQL statement: 

SELECT * FROM DTAB; 

The resulting display follows: 

REMARKS 


ORACLE catalog as of 10-May-84, installed on <date/time> 

Audit entries for accesses to user's tables/views (DBA sees all) 
Maps auditing action numbers to action names 
Audit trail entries for user logon/logoff (DBA sees all users) 

Audit trail entries for DBA activities -- for DBA use only 

Audit trail entries for objects which do NOT EXIST -- DBA's only 

Audit trail entries relevant to the user (DBA sees all) 

Profile of tables accessible to user, excluding data dictionary 
Clusters and their tables (either must be accessible to user 
Maps cluster columns to clustered table columns 
Specifications of columns in tables created by the user 
Specifications of columns in tables (excluding data dictionary) 
Public and private links to external databases 
Default table auditing options 

Description of tables & views in Oracle Data Dictionary 
Data structure of extents within tables 

Indexes created by user & indexes on tables created by user 
File structure of files within partitions — for DBA use only 
Private synonyms created by the user 
Public synonyms 

Record of login sessions for user 

Selection of space definitions for creating tables & clusters 
Data and Index storage allocation for user's own tables 
Synonyms, private and public 

Synonym for sys.audit_trail -- for DBA use only 
Profile of tables and views accessible to the user 
Directory of column level update grants by or to the user 
Specifications of columns in accessible tables and views 
All links to external databases — for DBA use only 
Data structure of tables throughout system — for DBA use only 
List of indexes, underlying columns, creator, and options 
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SYSPROGS 

SYSSTORAGE 

SYSTABALLOC 

SYSTABAUTH 

SYSTEM_AUDIT 

SYSUSERAUTH 

SYSUSERLIST 

SYSVIEWS 

TAB 

TABALLOC 

TABQUOTAS 

TABLE_AUDIT 

VIEWS 


List of programs precompiled by user 

Summary of all database storage — for DBA use only 

Data and index space allocations for all tables — for DBA's 

Directory of access authorization granted by or to the user 

System auditing options — for DBA use only 

Master list of Oracle users — for DBA use only 

List of Oracle users 

Quotations of the SQL text upon which system views are based 
List of tables, views, clusters and synonyms created by the user 
Data and index space allocations for all user's tables 
Table allocation (space) parameters for tables created by user 
Auditing options of user's tables and views (DBA sees all) 
Quotations of the SQL statements upon which views are based 


44 records selected. 

Although the column's heading is TNAME, the "tables" listed are actually 
views. The table DTAB is created by running CATALOG.ORA. Fur¬ 
thermore, the only data in DTAB which ever changes is the first row, 
showing the date and time CATALOG.OR A was last run. 


T he data dictionary is accessed exactly as any other data in ORACLE; it 
is just a set of predefined tables and views, with columns and rows just like 
user-defined tables. For example, to see the tables you own, you would 


type: 


SELECT * FROM TAB; 


TAB is the data dictionary view which displays the names and types of an 
ORACLE user's own data objects. 


HOW IS THE DATA DICTIONARY CREATED AND UPDATED? 


The data dictionary consists of several tables, and several views based upon 
those tables. The underlying tables are updated constantly by the 
ORACLE RDBMS during system operation, but arc not frequently ac¬ 
cessed by users, because the information is normalized, and much of it is 
stored by using numeric keys rather than easily understood names. 
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The views, on the other hand, "decode" the keys into their meanings, such 
as user or table names, and use joins and WHERE criteria. Thus, the 
views contain information in a form more convenient for users. 

The tables are automatically created during an lOR IN1T, and belong to 
the user SYS. These are the most basic tables visible to a user (though by 
default only DBAs have access to these tables), and include SYS.TABLES 
SYS.USERS, SYS.EXTENTS, and SYS.COLUMNS. 

The views which belong to user SYSTEM arc not automatically created, 
but are normally created at every site by running the file CATALOG.ORA 
using SQL*Plus. 

Throughout its use, the ORACLE RDBMS constantly updates the data 
dictionary tables. Naturally the views arc not updated, as they will always 
reference the most current data. 

For example, if user NANCY creates a table named PARTS, the table 
SYS.TABLES will gain a new row which identifies PARTS as belonging 
to NANCY; so Nancy's one SQL statement (CREATE TABLE...) gen¬ 
erated a new row in SYS.TABLES and some new rows in other data dic¬ 
tionary tables. The next time NANCY accesses the view TAB she will see 
the new table PARTS. 

Users should never directly update the data dictionary tables which 
ORACLE created (with very few exceptions, as noted below). 


NOTES ON THE INDIVIDUAL DICTIONARY TABLES 


Because data dictionary tables are frequently read and joined in the same 
manner, certain tables are clustered. For example, SYS.TABLES and 
SYS.COLUMNS are clustered on columns TABLES.TABSPID 
TABLES.TABSRBA and COLUMNS.COLSPID, 

COLUMNS.CO L$R BA. 
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ADDING NEW DATA DICTIONARY ITEMS 


Though it is dangerous to alter the existing data dictionary tables, it is 
permissable to add entirely new tables or views based on existing tables. 

However, to assure that the data dictionary as installed is altered in no way, 
it is preferable and recommended that you either make SYSTEM the 
owner of the new objects, or create a third ORACLE user with DBA 
privileges to own these objects. 


MANUALLY UPDATING THE DATA DICTIONARY 


With very few exceptions you may not alter data dictionary tables (do not 
DROP or ALTER tables, or DELETE, INSER T or UPDATE their data). 

However, if you have enabled auditing (see "Enabling System Auditing” 
on page 194) then you may wish to occasionally delete data from the table 
SYS.AUDlT l RAIL. This table will grow at a pace which depends on 
general system usage and which auditing options are being tracked; unlike 
the other data dictionary tables it is safe to delete data from this table. Do 
not alter the table or drop it, however. 

The DBA may also grant or revoke access to DBA-only views if he wants 
to alter the default accesses set up during installation. 
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CHAPTER 8. HOW IS DATA STORED IN THE DATABASE? 


This chapter describes how data is stored in a database, starting from the 
the most general picture to the most detailed — from a description of the 
database, to what elements compose a database, down to the distinct types 
of data. Data conversion and temporary tables are also discussed. 


THE DATABASE FILE 


An ORACLE database consists of a database file (DB file) which corre¬ 
sponds to one or more partitions and one or more files. 


Partitions and Files 


Every database consists of at least one partition. In a newly installed da¬ 
tabase there is always a SYSTEM partition. Additional partitions may be 
added at any time for reasons such as controlling placement of data and 
subsequent accesses of that data across disks. Partitions added after the 
SYSTEM partition can be given any name. 

Partitions are logical units. Every partition must correspond to at least one 
physical file. For example, in a newly installed database, the file named in 
the INIT.ORA file under the DATABASE parameter is the file which will 
correspond to the SYSTEM partition. Figure 21 on page 98 shows a da¬ 
tabase consisting of three logical partitions and five physical files. 
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DATABASE 



Figure 21. Diagram of Database Partitions and Files 


A partition must have at least one File; files can be added to a partition as 
required. The maximum number of files per database (sum of all files for 
all partitions) is system dependent. Refer to the Installation and User's 
Guide for your operating system to see the maximum for your operating 
system. The files may reside anywhere on the operating system. 

A single partition may contain many database tables. A table may span 
any or all of the files in a partition, but tables may not span partitions. 

To use a partition other than the SYSTEM partition, a table must be ex¬ 
plicitly created in that partition; see “Specifying a Partition when Creating 
a Table” on page 115. Indexes are stored in the same partition as the tables 
for which they were created. 


The SYSTEM Partition 

Every ORACLE system must have a SYSTEM partition. The SYSTEM 
partition usually contains: 

• the data dictionary tables 

• temporary tables 

• online help tables, if loaded (approximately 250 ORACLE blocks). 
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(In most installations these items will reside in the SYSTEM partition; with 
careful customization a site can install a system where these items do not 
reside in the SYSTEM partition.) 

When estimating the size of the SYSTEM partition's file, you should allow 
adequate room for these items as well as for any user data which will be 
entered to the SYSTEM partition. 

The first file (and often the only file) in the SYSTEM partition is the 
physical file named in INIT.ORA for the DATABASE parameter. The 
DBA can add files to the SYSTEM partition at any time. 


Adding Partitions and Files 

Partitions and files may be added, but never dropped, by users with DBA 
authority. Partitions are added in SQL*Plus with a SQL statement, as 
shown in Figure 22. In this example, we add a file to a new partition; if 
we were adding a file to the SYSTEM partition, we would only need the 
ALTER PARTITION statement because the partition SYSTEM would 
already exist. Because a partition is only a logical entity, a physical file 
must be associated with each new partition; this is accomplished by fol¬ 
lowing the creation of a partition with another SQL statement to add a file 
to the partition. 


SQL> CREATE PARTITION partition_name 
Partition created. 

SQL> ALTER PARTITION partition_name ADD FILE ‘filename 1 
Partition altered. 


Figure 22. Syntax for Adding a Partition and File 

T he specification of the filename varies by operating environment; see the 
Installation and User's Guide for your operating system for the exact file 
specification and examples of adding files to a partition. 

NOTE: Be careful to specify the file name correctly the first time. If 
ORACLE doesn't find a file with the specified name, an error is returned. 
Errors also result if files are specified incorrectly, as in renaming the file or 
logical assignments pointing to the file; these errors usually become appar¬ 
ent at the next warm start of the database. T he usual error is: 

unrecoverable recursion error 
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and the only solution is to re-initialize the database. As a precaution, 
therefore, it is recommended that you do a full database file backup or ex¬ 
port before adding a partition. 

If running a shared partition system (such as several ORACLE instances 
running an ORACLE Cluster on a VAXCluster), then the database must 
have been started without the SHARED option prior to adding or altering 
a partition. After successfully adding or altering the partition, restart 
ORACLE by entering: 

IOR WARM SHARED 

Do not add the same file twice. ORACLE RDBMS checks to verify that 
the filename is not a duplicate, but in some operating systems logical as¬ 
signments can be used to specify filenames, and some systems cannot de¬ 
termine whether those translate to an already-added file (VMS can so 
determine). 

The CCF Utility 

The CCF (Create Contiguous File) ORACLE utility is provided (for cer¬ 
tain operating systems) to allocate and "clean out" blocks to be used for 
database and before image files. If CCF is provided for your system, you 
should use CCF for every physical file which will be used by ORACLE, 
before naming it in the INIT.ORA file or adding it to a partition. Do not 
use CCF on existing files; you should use CCF to create new files. 

CCF syntax is; 

CCF filename sizeu 
where: 

filename is the file's name. It may be a logical assignment on operating 
systems which support logicals. 

size is the number of operating system blocks to be allocated. 

For example: 

CCF ORACLE.DBS 10240 


When the Partition is OUT OF SPACE 

As a database is used, eventually the SYSTEM partition or another parti¬ 
tion may fill up. When this happens, you'll see: 

OUT OF SPACE IN PARTITION 
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Following are two queries a DBA can use to see information about the 
current use of space in a database. The DBA can sec the number of free 
blocks still available for use by executing the query: 


SELECT SPM$PID, SPM$ENDBLOCK - SPM$STARTBLOCK + 1 
FROM SYS.SPACEMAP; 


SPM$PID SPM$ENDBL0CK-SPM$STARTBL0CK+1 


1 

1 

1 

1 


1788 

304 

66 

125 


Every row in the result lists the partition's id (SYSTEM is 1) and the 
number of free blocks in each set of contiguous free blocks. By adding all 
the numbers in the second column, you get the total number of all free 
blocks in all partitions. 


jC 


To successfully create a table, at least one set of free blocks must equal or 
exceed the number of blocks in the table's initial data and index extents. 
Similarly, for a growing table to acquire a new extent, enough contiguous 
blocks must be free to form the new extent. (See “Space Definitions” on 
page 108 for a description of the role of space definitions in table creation.) 


Fewer and larger sets of free blocks are preferable to many smaller sets of 
blocks. A database with many small sets of blocks is sometimes called a 
"fragmented" database. A fragmented database usually indicates the need 
to reorganize the database in order to make space available in larger 
"pieces". You can accomplish this by a full database export/import, or by 
selectively copying and dropping (or archiving) tables. 

Another helpful query shows the average size of space available by parti¬ 
tion: 


SELECT AVG(SPM$ENDBLOCK - SPM$STARTBLOCK + 1) "AVERAGE" 
MIN(SPM$ENDBLOCK - SPM$STARTBLOCK + 1) "MINIMUM" 
MAX(SPM$ENDBLOCK - SPM$STARTBLOCK + 1) "MAXIMUM" 
COUNT (*) "HOWMANY", SPM$PID "PARTITION" 

FROM SYS.SPACEMAP 
GROUP BY SPM$PID; 

AVERAGE MINIMUM MAXIMUM HOWMANY PARTITION 


1646 1 4797 3 1 
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If the numbers in this result are low, then space available for temporary 
tables or for new user data is constrained. Too little total space indicates 
the need to add a file to the database. Or, you might export some less- 
active tables and drop them, storing them offline until you need them again 
(at which point you may need to add space). 


TABLES 


Tables are the basic unit of data storage in an ORACLE database. Every 
table is defined (CREATEd) with a name and a set of columns. Columns 
are given a name, a datatype, and a width. After a table is created, rows 
of data can then be inserted into it. (A version of the CREATE TABLE 
statement allows you, in one statement, to create and load a table, based 
on other existing tables.) 

When a table is created, space is automatically reserved for that table's fu¬ 
ture data and future indexes. These two "spaces" are called segments. The 
initial size and increments by which the data segment and index segment 
can grow are controlled by the space definition used when creating the ta¬ 
ble. (See “Space Definitions” on page 108 for details on space definitions.) 

The data segment and index segment are made up of a number of extents 
of data blocks. Figure 23 on page 103 shows how data and index segments 
are composed of a number of extents; this example assumes a non-default 
space definition was used when creating table EMP. 
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Storage for Table EMP 


DATA SEGMENT INDEX SEGMENT 



Initial Data 


Initial Index 

Extent 


Extent 

(1000 blocks) 


(750 blocks) 



Increment 


Increment 

Data Extent 1 


Index Extent 1 

(500 blocks) 


(500 blocks) 



Increment 


Increment 

Data Extent 2 


Index Extent 2 

(500 blocks) 


(500 blocks) 


— 

Increment 


Increment 

Data Extent x 


Index Extent y 


Figure 23. Diagram of Data and Index Segments 


Logical Format of Non-Clustered Data Blocks 


Figure 24 on page 104 shows the logical format of data blocks for non¬ 
clustered tables. (See Figure 35 on page 166 to see the logical format of a 
clustered data block.) Each data block has its own overhead, including 
pointers to other (chained) blocks and a timestamp of when the block was 
last written. There is also overhead for each row and column (see next 
section). 
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Timestamp 


Row-x sequence no. 
Col-a id 


_ Type _ 

Next block's address 
Previous block's address 
I leader block 

Row-x length 
Col-a length 

Col-a data 


Col-b id 


Col-b length 


Col-b data 

{...and so on for additional columns and rows...} 
Unused space (originally set by PCTFREE) 


Figure 24. Logical Data Block format (Unclustcrcd) 


The size of an ORACLE logical block is operating system dependent. On 
most operating systems it is either 2048 bytes or 4096 bytes. ORACLE 
requires 76 bytes for overhead, leaving either 1972 bytes or 4020 bytes per 
logical block for user data. Of the 76 bytes of overhead, 44 bytes are used 
for the header of the physical data block , and 32 bytes are used for the 
header of the logical data block. 


Overhead Required by ORACLE 


ORACLE requires a certain amount of overhead for each table, row, and 
column, as described below. 

Every tabic requires 2 data blocks of overhead and 1 index block of over¬ 
head. 

The first data block is the "extent block"; it contains space information, 
such as the start address of each extent currently used by the table, the last 
block, and how many blocks in the extent. The start address of the first 
data block coincides with the TABSRBA for that table's data (which ap¬ 
pears in several data dictionary tables). 

The next data block contains information which duplicates data dictionary 
information (such as table definitions); storing this information here avoids 
the necessity of constantly referring to the data dictionary for internal 
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checks (and consequently locking the data dictionary for those frequent 
checks). The data dictionary block may occasionally require more than 
one block to hold its information. 

The one block of overhead required for an index segment is an "extent 
block" comparable to the one for data; it contains information on the cur¬ 
rent extents used by all indexes for that table. 

Every row has either four or five bytes of overhead. Two bytes store the 
row's total length in bytes, and two bytes store the row sequence number 
(the order the row was inserted into the block). If the row is in a clustered 
table, one more byte of overhead is required to indicate table number, for 
a total of five bytes. 

The row sequence number is specific to the block; every block will have 
a row with a row sequence number of 1 (unless the first row inserted to that 
block has been deleted). There are no duplicate row sequence numbers in 
the same block. Once a row sequence number is assigned in a block, it is 
never reused, even if its row is deleted. And, once assigned to a row it never 
changes for that row. 

Do not confuse the row sequence number with the ROWID. The row 
sequence number is physically stored and is a part of the ROWID. On the 
other hand, the ROWID is not stored and may change over time. Also, 
the ROWID is easily accessible through SQL. (Sec “The Datatype 
ROWID” on page 124 for a definition and discussion of ROWID.) Nor 
should you confuse the row sequence number with ROWNUM (a reserved 
keyword for use in SQL). 

Every column has two bytes of overhead. One byte stores the column 
identification number, and another byte stores the number of bytes of col¬ 
umn data. NULL columns do not require this overhead, as no part of a 
NULL column is stored. 


How Space is Used 


NOTE: The following discussion of space usage refers to terms associated 
with space definitions, which are discussed in “Space Definitions” on page 
108. 

When a table is created, space is immediately allocated for the initial data 
segment and initial index segment. As rows are inserted for the table, the 
initial data extent will fill its blocks. As indexes arc created on the table, 
the initial index extent will similarly fill its blocks. Three DML operations 
physically affect data in the data blocks: 
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• INSERT statements 

• UPDATE statements 

• DELETE statements. 

Index blocks are also affected by the DML statements, as the indexes must 
be continually updated to reflect the new data. The first CREATE IN¬ 
DEX statement begins to fill the first index extent for the table. CREATE 
INDEX will claim extents as it requires them. A DROP INDEX will free 
the index blocks used by that index for use by other indexes on the same 
table. 


Insertion 

Rows are inserted to a table in physical sequence. The first row is stored 
in the first block of the first extent; succeeding rows are stored in the first 
block until it is full. A block is full when a complete row cannot fit in the 
space available. Row data will not span blocks except for rows which 
cannot initially fit in one block, or rows which have been updated and must 
expand into another block. Column data cannot span blocks except for 
LONG data. 

The initial space available is the size of the ORACLE block (2048 bytes for 
most systems), minus the overhead per data block (76 bytes for unclustered 
data blocks on most systems) and the PCTFREE specified in the space 
definition (by default, 20% of the logical block size). 

When enough rows have been inserted to fill all blocks in the first extent 
allocated for the table, the first incremental extent is allocated. For exam¬ 
ple, for the default space definition, when the first 5 data blocks are full, 
ORACLE allocates an incremental extent of 25 blocks. Only when in¬ 
sertions have filled that extent will ORACLE allocate the next data extent. 

Space reserved for updates by the PCTFREE parameter of a space defi¬ 
nition is not available for insertion of new rows. 

If a clustered block runs out of space during inserts of new rows with that 
cluster key, the new row(s) are written to a chained block (see “Chained 
Blocks’’ on page 107) 


Updates 

Updates to data are written to the same block which contained the row 
before it was updated, using space in the following order: 

• available space in the block including space reserved by PCTFREE 

• space in a block "chained" to the current block. 
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As changes are made to the data values, the data remaining in the data 
block is compressed, to leave free space at the end of the block. As rows 
are deleted or updated, row numbers will not necessarily remain in order. 
Some sequences of insertions and deletions could cause rows with higher 
row sequence numbers to appear before rows with lower row sequence 
numbers. 


Chained Blocks 


Chained blocks are used in the following circumstances: 

• an insert of a row which is larger than an ORACLE block 

• an update to a row cannot fit in the current data block 

• an insert to clustered data will not fit entirely in the logical block for that 
cluster key. 

In all of these cases the row is written to a chained block. A chained block 
is an additional physical block making up a logical ORACLE block, and 
is created when updates require more space. If updates are substantial one 
logical block may consist of multiple chained blocks. ORACLE tracks the 
block addresses in the headers of the data blocks; in Figure 24 on page 104 
note the next block's address , the previous block's address (referring chained 
blocks, if any), and header block (the original data block's address). The 
chained block can be in the same extent or a different extent. 

As retrieval of "chained data" is slower than searching for data which is 
physically sequential, you should include the expected amount of updating 
in your estimate of PCTEREE when creating space definitions. For ex¬ 
ample, if you load data into a table where many columns are NULL but 
will be given data values later, you should increase the PCTEREE param¬ 
eter significantly. 

If all the data found in a chained block is deleted, the chained block be¬ 
comes available for reuse by that table. 


Deletions 


When one row in a block is deleted, space is returned to the block, and can 
be used for updates to remaining rows. (Once a data block has been filled, 
no new row can be added, unless the block becomes empty.) If all rows 
in a block are deleted, the block is freed for use by that table or cluster. 

A data block is only returned for general use by ORACLE when its table 
or cluster definition is dropped. 
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How Space is Regained 


Once an extent is allocated for a table's data or index segment, it is not 
released (until the table is dropped). It will always appear in the data dic¬ 
tionary (for example, in the view STORAGE) as allocated to that table. 

However, if all data in a data block is deleted (all its rows are deleted), then 
that block becomes available for reuse by that table or cluster. Similarly, 
if all data in an index block is deleted, the block remains allocated for in¬ 
dexes on that table, until the table is dropped. All chained blocks, except 
for the header block, become available for reuse if all their data is deleted. 

Therefore, even though S TORAGE may show all extents for a particular 
segment "in use", there may be more room to add data or indexes, because 
you cannot tell how full an extent is. 

When a table is dropped, all blocks are returned as free space, to be used 
for data or indexes of other tables. 


SPACE DEFINITIONS 


Space definitions allow you to control how a table uses database space and 
the maximum amount of storage it can use. For every table that is created, 
a space definition controls that table's potential storage. The definition is 
either the default space definition, built into the ORACLE RDBMS, or 
one created by a user. All existing space definitions are available to all users 
to reference. 

Space definitions are also used to control which partition a table is stored 
in. See “Specifying a Partition when Creating a Table” on page 115. 

A space definition controls the amount of space which can be used by a 
table's data and indexes. The limit applies to all table data and all indexes 
created on that table (not each index). One space definition can be used 
by many tables; the creation of the space definition itself is independent of 
the creation of the table. To associate a table and a space definition, the 
space definition is named in the CREATE TABLE statement, as in: 

CREATE TABLE LOTSANUMBERS (ALLOWANCE NUMBER, RECEIPT_DAY DATE) 
SPACE BIGSPACE; 

where BIGSPACE is an existing space definition. 
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The Space Definition DEFAULT 


The default space definition is shown in Figure 25. 


CREATE SPACE DEFINITION DEFAULT 
DATAPAGES (INITIAL 5, 

INCREMENT 25, 
MAXEXTENTS 9999, 
PCTFREE 20) 

INDEXPAGES (INITIAL 5, 

INCREMENT 25, 
MAXEXTENTS 9999) 
PARTITION SYSTEM; 


Figure 25. The DEFAULT Space Definition 

Following are descriptions of the various parameters of a space definition. 

DATAPAGES refers to the blocks making up the data segment; 

INDEXPAGES refers to the blocks in the index segment. 

INITIAL The number of blocks in the first allocation of blocks. An initial 
allocation is made for data and an initial allocation is made for 
indexes. The minimum allowed for both data and index initial 
extents is 3 blocks. The number of initial data extents need not 
be the same as for index extents. At the time of table creation 
enough contiguous blocks must be free for both allocations. 

INCREMENT After the blocks in the initial extents arc filled with data, 
and when the user data or indexes require more space, then an¬ 
other set of blocks is allocated. The INCREMENT parameter 
determines how many blocks will obtained when more space is 
allocated. 

MAXEXTENTS This parameter indicates how many limes ORACLE can 
allocate an incremental extent. Unless you really want to impose 
a limit on the space a table can use, this parameter should be set 
very high; to increase the limit once it has been reached requires 
some effort. 

For the default space definition the MAXEX TENTS parameter 
is 9999; however, the actual maximum is operating system de- 
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pendent. For example, on VAX/VMS the maximum is about 
475 extents, and on MS-DOS the maximum is about 110. Refer 
to the Installation and User's Guide for your system to see its 
maximum. The maximum is set to 9999 so that if tables and data 
are exported on one operating system and imported to another, 
the maximum number of extents is not constrained to the lower 
limit of the two systems. 

PCTFREE The PCTFREE parameter indicates what percent of the logical 
block size (minus 32 bytes of physical overhead) will be reserved 
for updates made to the data. The minimum PCTFREE pa¬ 
rameter is 1; the maximum is 99. 

PARTITION To specify that the table use any partition other than SYS¬ 
TEM, the alternate partition's name must be specified here. 

For example, when a table is created using the default space definition 5 
ORACLE blocks are set aside immediately for the table's data, and 5 
blocks are also set aside for its indexes (the parameters INITIAL under 
DATAPAGES and INDEXPAGES). When the number of rows in that 
table has grown so that the table's data fully occupies 5 blocks, the in¬ 
sertion of the next row requires allocation of an extent to the table. For 
the default space definition, a data extent has 25 ORACLE blocks (the 
parameter INCREMENT under DATAPAGES). 


The Space Definition TEMPTABLE 


A space definition named TEMPTABLE is used by ORACLE to create 
all its temporary tables; refer to “The Space Definition TEMPTABLE” 
on page 129. 

Listing Current Space Definitions 


To see what space definitions are currently defined, any user may query the 
data dictionary view SPACES, which shows all definitions currently de¬ 
fined. You should always see at least one definition, named 
TEMPTABLE, which is the space definition used by ORACLE when it 
creates temporary tables. 
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Creating a Space Definition 


Any user with RESOURCE privilege may define a space definition. The 
general syntax of creating a space definition is shown in Eigure 26. 


CREATE SPACE [DEFINITION] space.name 
DATAPAGES (INITIAL n, 

INCREMENT n, 
MAXEXTENTS n, 

PCTFREE n) 

INDEXPAGES (INITIAL n, 

INCREMENT n, 
MAXEXTENTS n) 
PARTITION partition_name 


Figure 26. CREATE SPACE Syntax 

Though you can name a space definition anything you want, it is a useful 
practice to associate the definition with the table it will be used for (for 
example, use a space definition named SP_EMP for the EMP table). Re¬ 
gardless of the name, however, a space definition may be used by any user 
or any table. 

You need not specify every parameter under DATAPAGES or 
INDEXPAGES; parameters not specified will be the same as in the default 
space definition. The partition need only be specified if it is not the SYS¬ 
TEM partition. 

Note that the creation of the space definition does not allocate any space ; 
space is first allocated when a table (or cluster) is created, according to the 
space definition controlling the table (or cluster). Then, as data is 
INSERTed or UPDATEd, additional space will be acquired, subject to the 
space definition. 


Calculating the Number of Data Segments 

Some general recommendations for using space definitions are: 

• Fewer, larger extents are preferred over more, smaller extents. Opti¬ 
mally, all data for a table should be in its first extent. 

• Updates can make individual rows wider. For example, if many rows 
are inserted, but certain columns are left NULL to be filled in later, then 
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the PCTFREE parameter should probably be increased. The updates 
will necessarily take more space, because NULLs use none. 

• Unless you really want to set a ceiling on the amount of space a table 
can use, do not specify the MAXEXTENTS parameter. 

• Remember that enough logically contiguous blocks must be available to 
form the initial data and index extent when the table is created, and log¬ 
ically contiguous blocks are also needed for incremental data or index 
blocks. 

A general formula follows for estimating the initial number of data blocks 

to use in a space definition. This formula assumes you are estimating the 

size of a single nonclustered table. It takes the following items into con¬ 
sideration: 

• number of rows per table 

• average length of variable length data 

• percent of NULL data for each column (thus the expected length of in¬ 
serted rows) 

• amount of updating, particularly that which will expand row length. 

The formula uses the variables: 


INPUT: 


R Number of rows in the table 

Ci Average length of ith item 

Ni Fraction of ith column with null value 
F Percent free in each block (PCTFREE parameter) 

ORACLE SPECIFIC (based on operating system and ORACLE version): 


K 

I 

L 

Q 

S 

H 


Column length Indicator 
Column id number 
Row length 
Row sequence number 
ORACLE logical block size 
ORACLE header info per block 


(VAX=1) 

(VAX=1) 

(VAX=2) 

(VAX=2) 

(VAX=2048, VM=4096) 
(VAX=76) 
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CALCULATED RESULTS: 


BR Average number of bytes per row 

RB Average number of rows per ORACLE BLOCK 

SUM1 Sum taken over all values of 1 
B ORACLE logical blocks required for table 

First, calculate the average bytes per row: 


BR = SUMi [(1 - Ni) * (Cl + K + I)] + L + Q 


Second, calculate the average rows per block: 


RB = integer portion of 


(1-F) * (S-H) 
BR 


Third, calculate the number of blocks (Use B as the INITIAL parameter 
for DATAPAGES): 


B = 


R 

RB 


Calculating the Number of Index Segments 

In general it is difficult to precisely estimate the space required for indexes. 
It depends on: 

• distribution of values in the indexed column(s) (the number of distinct 
values in the columns and how different one value is from the next) 

• how many columns are indexed 

• the length of the indexed columns 

• the percent of NULLs 

• whether the index is created compressed or noncompressed 

• whether the index is created before or after the table's data is loaded. 

Note that all indexes for a table are stored in the same index segment. 
Cluster keys are also stored in the index segment. A rule of thumb is that 
about 20-30% of the space required for the table is required for indexes. 
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A formula can be used to estimate the number of blocks. It uses the vari¬ 
ables: 

R Number of rows in the table 

S Block size for particular machine (typically 2048 or 4096) 

H Header bytes per block (usually 76) 

KL Estimated key length 

= 10 for COMPRESSED indexes 

= 16 + (number of columns in key) + (sum of lengths 

of columns in key) 


The formula is: 


R 

B = 1.1 * - 

(S - H) * .75 


KL 

The .75 factor is the approximate percentage of an index block that is in 
use, because blocks of B-trec indexes in general (except the root) vary from 
half-full to full. This factor also assumes a PCTFREE of 25; if you are 
calculating the blocks for an existing table created with the default space 
definition, use .80 instead of .75. 

The additional 10 percent factor is added to account for the upper nodes 
of the B-tree. 

For example, assume you are doing a CREATE INDEX on a 10,000 row 
table, the logical block size is 2048, you want I’CTFREE to be 20, and the 
one index is compressed and on a single 20 byte column: 


Compressed = (1000 / ((1984 * .80) / 10)) * 1.10 = 70 blocks 
Index Size 


Or, if the index were noncompressed: 


Noncompressed = (10000 / ((1984 * .80) / 37)) * 1.10 = 275 blocks. 

Index Size 
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Calculating Space Requirements for Clusters 

NOTE: For a general description of clusters and when to use them, refer 
to “Clusters” on page 165. 

Try to allow one logical cluster block for each unique cluster key. If more 
data is associated with the key than will fit in a logical block, additional 
data is placed in chained blocks, which somewhat defeats the purpose of 
clustering. 

The PCTFREE parameter is meaningless for clusters. 

Index segments for clusters should be allocated to contain all indexes for 
all tables in the cluster and the cluster key. 


Using a Space Definition 


To associate a table and a space definition, the space definition is named 
in the CREATE TABLE statement, as in: 

CREATE TABLE LOTSANUMBERS (ALLOWANCE NUMBER, RECEIPTJJAY DATE) 

SPACE BIGSPACE; 

where BIGSPACE is an existing space definition. When no space defi¬ 
nition is explicitly named, the default definition controls the table. When 
the table is created, ORACLE allocates two separate sets of blocks: for the 
table's datapages and indexes. 

Once a table is created using a space definition, as that table grows it will 
follow space guidelines set by that definition even if the definition is sub¬ 
sequently dropped or altered. 


Specifying a Partition when Creating a Table 


By default all tables allocate blocks in the SYSTEM partition. To desig¬ 
nate that a table use a different partition, you must do two things: 

1. Identify (CREATE if necessary) a space definition which specifies the 
desired PARTITION name. 

2. CREAT E the table with the SPACE option naming that space. 

In the following example, we create a new space definition, MEDSPACE, 
which specifies partition TESTDATA. T hen we create a table, AC- 
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COUNTS, using space MEDSPACE, so space will be allocated from the 
TESTDATA partition: 


SQL> CREATE SPACE DEFINITION MEDSPACE 
DATAPAGES (INITIAL 250, 
INCREMENT 100, 
MAXEXTENTS 999, 
PCTFREE 25) 

INDEXPAGES (INITIAL 100, 
INCREMENT 100, 
MAXEXTENTS 999) 
PCTFREE 25) 
PARTITION TESTDATA; 


Space definition created. 

SQL> CREATE TABLE ACCOUNTS (ano number, aname char (40)) 
SPACE MEDSPACE; 


Altering Space Definitions 


You can change allocations for existing space definitions, though this will 
only impact tables created after the change and not tables already created 
with the old space definition. The syntax is parallel to the CREATE 
SPACE DEFINITION syntax, and is shown in Figure 27. 


ALTER SPACE space_name 
DATAPAGES (INITIAL n, 
INCREMENT n, 
MAXEXTENTS n, 
PCTFREE n) 
INDEXPAGES (INITIAL n, 
INCREMENT n, 
MAXEXTENTS n) 
PARTITION partition_name 


Figure 27. Changing a Space Definition 
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You can change any parameter by specifying it in the command; any pa¬ 
rameter not specified remains unchanged. 


Dropping Space Definitions__ 

Any user with RESOURCE privilege may drop a space definition with the 
syntax: 

DROP SPACE space_name; 

Users can use or drop any definition except TEMPTABLE. Only the 
DBA can DROP or ALTER the TEMP TABLE definition. 

When A Table Exceeds Maximum Extents 


If a table grows so that it requires more than its maximum number of ex¬ 
tents, you will see the message: 

MAXIMUM NUMBER OF EXTENTS EXCEEDED 

Though you can alter the space definition, it will have no impact on the 
limits for that table, which are already set. However, you can use either 
of the following procedures. 

If the database has adequate space, the following procedure is recom¬ 
mended: 

1. CREAT E a table of the same structure but with a different name and 
in a larger space, and load it with the tabic which has run out of space: 

CREATE TABLE temp_new 
AS SELECT * FROM old_big_table 
SPACE bigger_space; 

2. DROP the older table 

3. RENAME the newer tabic to the name of the table you just dropped. 
If space in the database is a concern, then the following steps arc useful: 

1. EXPort the table. 

2. DROP the table's definition 
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3. CREATE a space definition with higher limits or parameters. 

4. CREATE the table specifying the new space definition. 

5. IMPort the table, specifying to Ignore Create Errors (as the table already 
will exist when Import tries to create it). 


ORACLE DATATYPES 


Data in an ORACLE RDBMS is stored as rows in tables. A table may 
contain as many as 254 columns, and each column is specified as one of 
the following ORACLE datatypes: 

• CHAR 

• NUMBER 

• DATE 

• LONG 

• RAW or LONG RAW 

All non-null column data is stored with a one-byte length parameter, and 
a one-byte column identifier. NULL character strings are not stored. 

Eoilowing are details on the different datatypes. 


CHAR Datatype 


Character data is stored in variable length strings of ASCII or EBCDIC 
values. Any alphanumeric character may be stored. The maximum length 
of a CHAR column is specified at table creation; the maximum number 
of characters which can be stored in any column defined as CHAR is 240. 
Trailing blanks are not stored unless they arc explicitly used inside quoted 
strings in the INSERT statement. 

Using the DUMP function, you can see the actual values stored for the 
table TEST: 
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SQL> SELECT CHARDATA, DUMP(CHARDATA) FROM TEST; 


CHARDATA DUMP(CHARDATA) 


a 

Typ=l 

Len= 

1; 

129 

ab 

Typ=l 

Len= 

2: 

129,130 

ab c 

Typ=l 

Len= 

4: 

129,130,64,131 

one 1 

Typ=l 

Len= 

5: 

150,149,133,64,241 


NUMBER Datatypes 


Numbers of virtually any magnitude may be stored, up to approximately 
38 digits of precision. Numbers as high as 100 to the 64th power, or 1 
followed by 128 zeroes, can be stored. If desired, users can specify precision 
(total number of digits) and scale (number of digits to right of decimal 
point), as in: 

CREATE TABLE MINI (weenumbers number (2,1)); 

Internal Numeric Format 

Numeric data is stored in variable length format, starting with an exponent 
and sign byte, followed by data bytes. A maximum of 19 data bytes can 
be used; each byte contains two decimal digits. 


<sign/exponent> digit-1 digit-2 digit-3 ... digit-19 


Figure 28. Internal Numeric Format 

T he sign bit is the high-order bit of the exponent byte. If it is set, the 
number is positive; if it is clear, the number is negative. 

The exponent is the low-order seven bits of the exponent byte. The expo¬ 
nent is base-100, can range from 0 to 127, and is in cxcess-64 notation. 

T he result of 64 subtracted from the exponent tells how many bytes to shift 
the number, where each shift is a multiply or divide by 100. If the result 


Chapter 8. Mow is Data Stored in the Database? / 119 









is negative, then the number is to be shifted to the right of the implied radix 
point; if the result is positive, then the number is to be shifted to the left. 

Each digit represents a binary number from 0 to 99, representing a base-100 
digit. Each digit has 1 added to it to prevent binary 0 from occurring as a 
number. Thus, the actual internal representation of each digit is a binary 
number from 1 to 100. The first digit is always non-zero because all 
numbers are normalized. The radix point is to. the left of the first digit. 

Negative numbers are transformed positive numbers. The transformation 
of positive numbers to negative numbers assures that all ORACLE num¬ 
bers will collate correctly. The transformation method follows: the nega¬ 
tive exponent byte, including the sign bit, is the one's complement of the 
positive exponent byte. Each negative digit is the 100's complement of its 
corresponding positive digit, plus one. This means that a positive digit is 
subtracted from 100 to get the corresponding negative digit. If a negative 
number does not have the maximum number of digits then a byte con¬ 
taining 102 is appended to the number. 

Zero is a one-byte number containing 128. This is the exponent byte, with 
the sign bit set and the smallest possible exponent (-64). This guarantees 
that zero will collate below all positive numbers and above all negative 
numbers. 

Positive infinity is represented by two bytes [255,101]; negative infinity is 
represented by three bytes [1,1,102]. These representations were chosen so 
the two infinities would collate correctly. 


Using Scale and Precision on Numbers 

When specifying numeric fields, it is a good idea to specify the maximum 
number of digits and decimal places to keep. This prevents numeric values 
from using all digits of precision and unnecessary space. 

Eigure 29 gives examples of how Vlata would be stored using different scale 
factors. 


ACTUAL DATA 

SPECIFIED AS 

STORED AS 

7,456,123.89 

NUMBER 

7456123.89 

7,456,123.89 

NUMBER (9,2) 

7456123.89 

7,456,123.89 

NUMBER (9,1) 

7456123.9 

7,456,123.8 

NUMBER (6) 

(not accepted - exceeds precision) 

7,456,123.89 

NUMBER (7,-2) 

7456100 

Figure 29. Examples 

of Scale and Precision on Numeric Data 
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If the number of decimal places is negative, the number is rounded to the 
number of places indicated (for example, a specification of (10,-2) means 
to round to hundreds). 


DATE Datatype 


Date data is stored in fixed length fields of seven bytes each. For each date 
the following information is stored: 


BYTE: 1234567 

Century Year Month Day Hour Minute Second 

as in: 19 85 4 1 15 15 45 

for the date/time April 1, 1985 3:15:45 p.m. 

By default, the time in a date field is 12:00 a.m. (midnight) if no time por¬ 
tion is entered. To enter dates which arc not in standard ORACLE date 
format, you must use the TO DATE function with a format mask. Sum- 
larly, to enter the time portion of a date, the TO DA I E function must be 
used with a format mask indicating the time portion, as in: 


SQL> 


INSERT INTO BIRTHDAYS (JUSTWHO.BDAY) VALUES ('ANNIE', 
T0_DATE('13-N0V-85 10:56 A.M.', 'DD-MON-YY HH:MI A.M. ); 


Using Julian Dates 


The format mask "J" can be used with date functions (TO DAT E or 
TOC1IAR) to convert date data into Julian dates. For example: 

SELECT TO.CHAR (HIREDATE, 'J') FROM EMP 

will show all hiredates in Julian date format. (T he TO NUMBER func¬ 
tion must also be used if you want to use Julian dates in calculations.) 

There are different interpretations of what is a Julian date; the calculation 
method used by ORACLE results in a 7 digit number (for dates most often 
used), as in 2444993 for 23-JAN-82. The intent of Julian dates is to allow 
continuous dating from a common reference. (T he reference is some 4000 
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years B.C., so current dates are somewhere in the 2.4 million range.) A 
Julian date is nominally a non-integer, the fractional part being a portion 
of a day. ORACLE uses a simplified approach which results in integer 
values. 


LONG Datatype 


Columns defined as LONG can store variable length character strings 
containing up to 65,536 characters. LONG data is simply an unstructured 
set of bytes of data. The only way it differs from LONG RAW is that if 
transmitted by SQL*Nct, LONG data may be converted to a different 
character set, whereas LONG RAW data is not converted. 

LONG data can be used to store arrays of characters, or even a short 
document. LONG datatypes are used in the data dictionary to store the 
text of view definitions. Columns defined as LONG can be used in SE¬ 
LECT lists, SET statements and INSERT statements. 


Restrictions on LONG Data 

Though LONG columns have many uses, there are some constraints on 
their use due primarily to their size: 

• Only one LONG column is allowed per table. 

• Tables containing LONGs cannot be clustered. 

• LONG columns cannot be indexed. 

• LONG columns cannot be referenced in WHERE, GROUP BY, OR¬ 
DER BY, CONNECT BY, or DISTINCT clauses. 

• No functions (such as SUBSTR or INSTR) can be used on LONG data. 

• LONG columns may not be in the SELECT list of nested queries. 

• LONG columns may not appear in expressions. 

• LONG columns may not appear in the SELECT list of a query block 
which is UNIONed, INTERSECTed, or MINUSed with another query 
block. 
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Using LONG Data in SQL*Plus . 

When using LONGs in SQL + Plus, you may find the following two 

SQL*Plus settings useful: 

SET LONG n 

COLUMN longcolname FORMAT An W0RD_WRAP 

where An is a format mask for character data of n digits in width. 


Using LONG Data in User-Written Programs 

Host variables declared in user written programs can be any supported host 
language datatype. The ORACLE datatype should be type 5 (raw data) 
to avoid ORACLE'S trimming trailing blanks or rejecting nulls (binary 
zeroes) in the middle of LONG data. 


RAW and LONG RAW Datatype 


The RAW and LONG RAW datatypes, new in Version 5, are used for 
byte oriented data that is to be uninterpreted by ORACLE. RAW is 
similar to CHAR data (and LONG RAW is like LONG) except that no 
assumptions arc made about the meaning of the bytes. T hese datatypes 
are intended for binary data or byte strings, for example, to store graphics 
character sequences. 

RAW data is equivalent to CHAR (and LONG RAW to LONG) except 
when transmitted by SQL + Nct, at which time CHAR is converted to a 
different character set, if necessary, and RAW is not). 


SQL/DS Compatible Datatypes 


In addition to ORACLE datatypes, the SQL, statements: 

CREATE TABLE... 

CREATE CLUSTER... 

will accept datatypes from IBM's products SQL/DS and DB2, and 
internally convert them to ORACLE datatypes as shown in Eigure 30 on 
page 124. 
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SQL/DS 

DATATYPE 

ORACLE 

DATATYPE 


SMALLINT 

NUMBER 


INTEGER 

NUMBER 


DECIMAL(m,n) 

NUMBER(m.n) 


ELOAT 

NUMBER 


VARCHAR(n) 

CIIAR(n) 


LONG VARCHAR 

LONG 


GRAPHIC 

no corresponding datatype 


VARGRAPHIC 

no corresponding datatype 


LONG VARGRAPHIC 

no corresponding datatype 

Figur 

c 30. Conversion of SQL/DS Datatypes to ORACLE Datatypes 


Because they have no corresponding ORACLE datatype, the SQL/DS 
datatypes GRAPHIC, VARGRAPIIIC, and LONG VARGRAPHIC 
should never be used. However, all SQL/DS datatypes are reserved words, 
and so cannot be used to name database objects such as tables, columns, 
views, or indexes. 


The Datatype ROWID 


Associated with every row in the database is a logical column which cor¬ 
responds to the address of that row. That address can be retrieved in a 
SQL query using the reserved word ROWID. As the following example 
shows, a query selecting ROWID will return a result with a hexadecimal 
representation of the address for each row selected: 

SELECT ROWID, ENAME FROM EMP; 

ROWID ENAME 


00004618.0001.0001 SMITH 
00004618.0002.0001 ALLEN 
00004618.0003.0001 WARD 
00004618.0004.0001 JONES 


The ROWID returns three pieces of information necessary to locate a row: 
• which partition it's in 
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• which block in that partition 

• which row in that block. 

The format of a rowid is shown in Figure 31. 


LOGICAL PARTITION ROW SEQUENCE PARTITION 
BLOCK NUMBER NUMBER ID 

For example, the second row in block 4CE8, in the SYSTEM partition 
(partition 1) is: 00004CE8.0002.0001 

Figure 31. Format of ROWID 


The logical partition block number indicates which logical block in the 
partition contains the row. The last bits (the last 3 bits on VMS but varies 
by operating system) show the logical block within the physical block. The 
remaining (first) bits identify the physical block within the partition. 

The row sequence number is the same row sequence number which is stored 
as overhead for each row (see Figure 24 on page 104 or Figure 35 on page 
166.) 

The following query run under VAX/VMS, selecting ROWID for all re¬ 
cords in EMP, shows that the data is stored in partition 1 (SYSTEM), in 
relative block 2CAB0, with 14 records in a 2048 byte ORACLE block (on 
VMS). 
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SQL> select rowid, ename from emp; 


ROWID ENAME 


0002CAB0.0001.0001 SMITH 
0002CAB0.0002.0001 ALLEN 
0002CAB0.0003.0001 WARD 
0002CAB0.0004.0001 JONES 
0002CAB0.0005.0001 MARTIN 
0002CAB0.0006.0001 BLAKE 
0002CAB0.0007.0001 CLARK 
0002CAB0.0008.0001 SCOTT 
0002CAB0.0009.0001 KING 
0002CAB0.000A.0001 TURNER 
0002CAB0.000B.0001 ADAMS 
0002CAB0.000C.0001 JAMES 
0002CAB0.000D.0001 FORD 
0002CAB0.000E.0001 MILLER 


Why use ROWlDs? 

If the actual values returned by ROWID are so cumbersome, why would 

a user be interested in them? Rowids actually have several important uses: 

• T hey are the fastest means of accessing a particular row. 

• They can be used to see how many blocks of storage a table requires. 

• They can be used to obtain row-level locks. 

Though rowids can sometimes be accessed like table columns (used in the 

SELECT or WHERE clause), note that they cannot always be treated like 

columns, for the following reasons: 

• A ROWID is not guaranteed to be constant for any row over time. 
(The physical location of a row may change when the row is updated, 
or if exported and re-imported.) 

• A ROWID is not stored in the database. Though it can be referenced 
like ordinary data, it is not another column of data. Thus, it would not 
make sense to UPDATE, INSERT or DELETE a ROWID. 


Examples of Using ROWID 

Using some group functions along with ROWID, you can glean all sorts 
of useful information about how data is internally stored in the ORACLE 
database. First, note how the function SUBSTR can be used to break the 
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data in ROWID into its three separate components (partition block num¬ 
ber, row sequence number, and partition id): 


SQL> SELECT ROWID, 
2 

3 

4 FROM TABLEA; 


SUBSTR(ROWID, 1,8) BLOCK, 
SUBSTR(ROWID,10,4) RSN, 
SUBSTR(ROWID,15,4) PID 


ROWID 


BLOCK RSN PID 


00004618.0001.0001 0004618 0001 0001 


The following query will tell us how many of the blocks allocated arc ac¬ 
tually used by a table's current data: 

SQL> SELECT COUNT(DISTINCT(SUBSTR(ROWID,1,8))) BLOCKS 
2 FROM tablename; 

Note that this result reflects only data blocks used, not allocated to the ta¬ 
ble, as it does not include the two blocks required for each table's overhead, 
nor the number of "chained" blocks, nor blocks which were allocated in the 
extent but do not yet have data. 

The following query tells how many records arc in each block belonging 
to a particular table: 

SQL> SELECT SUBSTR(ROWID,1,8) BLOCK, C0UNT(*) 

2 FROM tablename 

3 GROUP BY SUBSTR(ROWID,1,8); 


Data Conversion 


A WHERE clause can use two different datatypes in its comparisons. If 
a WHERE clause mixes datatypes ORACLE can often use data conversion 
to resolve the statement. For example: 


1. SELECT ENAME 

2. SELECT ENAME 

3. SELECT ENAME 

4. SELECT ENAME 


FROM 

FROM 

FROM 

FROM 


EMP WHERE ENAME = 135 
EMP WHERE EMPNO = ’7936' 

EMP WHERE HIREDATE = '12-MAR-86' 

EMP WHERE ROWID = '00002514.0001.0001' 
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To perform the conversion, ORACLE can either: 

• convert the constant to the column's defined datatype, or: 

• convert the column's value to the datatype of the constant 


TEMPORARY TABLES 


Though users never directly see, create, or use the type of temporary table 
described in this section, the ORACLE RDBMS often requires temporary 
tables to complete user transactions. T his section offers some detail about 
when the tables are used, and what control a DBA has over their use. 

Operations Requiring Temporary Tables 


The following SQL operations may require ORACLE to create or use a 
temporary table: 

• CREATE INDEX 

• ORDER BY 

• DISTINCT 

• GROUP BY 

• UNION, INTERSECT, or MINUS 

• unindexed joins 

• certain correlated subqueries 

For example, if a query contains a DISTINCT clause, a GROUP BY, and 
an ORDER BY, it could require up to three temporary tables. 

A temporary table is not created if the sorting operation (such as ORDER 
BY) can be done in memory, or if the optimizer finds some other way to 
perform the operation. 
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How Temporary Tables are Used 


When a database is initialized or warm started, no temporary tables exist. 
As the database is used, temporary tables are required for the operations 
listed above, and created as needed. After a statement is through with a 
temporary table, the table becomes available for re-use by another state¬ 
ment. 

ORACLE always creates as many temporary tables as are needed. An 
INIT.ORA parameter, TEMP_TABLES, determines the number of tem¬ 
porary tables which ORACLE maintains , once created, after a warm start. 
For example, if TEMPTABLES were set to 20, but at some point 25 were 
in use, then the first five to become "free" would be dropped. 


The Space Definition TEIMPTABLE 


A system is initialized with a default space definition for all temporary ta¬ 
bles, which can be seen in the view named SPACES as the definition 
named TEMPTABLE. 

The space definition for temporary tables is: 

CREATE SPACE DEFINITION TEMPTABLE 
DATAPAGES (INITIAL 20, 

INCREMENT 100, 

MAXEXTENTS 240, 

PCTFREE 1) 

INDEXPAGES(INITIAL 20, 

INCREMENT 100, 

MAXEXTENTS 240) 

PARTITION SYSTEM; 

(T hough indexpages are defined they are not used for temporary tables.) 
By default, temporary tables arc created in the SYSTEM partition. 

T hough the definition can be changed (to increase or decrease allocations 
or to change the partition), it should never be dropped. 

If the space definition named TEMPTABLE is dropped, errors will occur 
during queries which require the creation of temporary tables. For exam¬ 
ple: 

space definition name does not exist 
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A space definition named TEMPT ABLE should be recreated before re¬ 
running the query. Only a DBA can DROP or ALTER the 
TEMPTABLE space definition. 


130 / The ORACLE Database Administrator's Guide 









CHAPTER 9. CONSISTENCY AND CONCURRENCY 


This chapter defines transactions and SQL commands to control them. It 
also lists, defines, and illustrates the numerous locks which ORACLE uses 
to guarantee data integrity among multiple users. The three modes of 
locking are compared: exclusive mode, share mode, and share update (or 
row-level) locking. Deadlock detection and resolution are also discussed. 


LOGICAL UNITS OF WORK (TRANSACTIONS) 


A logical unit of work is a sequence of SQL statements that ORACLE 
treats as a single entity. Logical units of work are also called transactions. 
ORACLE ensures data consistency based on logical units of work: for ev- 
ery logical unit of work, all of its operations are completed (made perma¬ 
nent in the database) or none of the operations are. If a system or user 
program fails while a logical unit of work is in progress, the database is 
automatically restored to the state it was in previous to the transaction 
starting. 

For example, if money is to be deducted from one account and added to 
another account, then both updates should cither succeed together or fail 
together. If an error occurs making the updates, neither update is made. 

When a user's program fails, ORACLE restores the data after detecting the 
error. When the operating system fails, the data is restored when 
ORACLE is restarted. 

A transaction may range from all the operations on the database for an 
entire program to a single SQL update statement. In many programs it is 
practical to divide the operations of a user's program into subsets of logical 
units of work. In these programs, the SQL commands COMMIT and 
ROLLBACK are used to finish one unit of work and begin another. 
(COMMIT makes the changes "permanent" and ROLLBACK "undoes" 
all changes made in that transaction.) 
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A logical unit of work begins when the first executable SQL statement is 
encountered. A logical unit of work ends as soon as one of the following 
occurs: 

• COMMIT or ROLLBACK invoked 

• DDL command issued (such as CREATE, DROP, RENAME, AL¬ 
TER) 

• certain errors (such as deadlocks) 

• logoff (such as EXEC SQL ... RELEASE) 

• abnormal termination 

After one unit of work ends, the next executable SQL statement will au¬ 
tomatically start the next unit of work. If there is no COMMIT or 
ROLLBACK work statement in a program, normal termination of the 
program will commit the transaction in progress at termination. 


THE COMMIT WORK STATEMENT 


The COMMIT WORK statement makes "permanent" all operations in the 
current logical unit of work (naturally, the data may be changed by future 
updates) and it ends that unit of work. 

Recommended practice is to explicitly end transactions in application pro¬ 
grams using the COMMIT WORK (or ROLLBACK WORK) statement. 
If you do not explicitly commit the transaction and the program terminates 
abnormally, the last uncommitted unit of work will be rolled back. 

What Happens When You Commit 


When a transaction is committed, explicitly or implicitly, the following 
occurs: 

1. Any before images for blocks in this transaction which have not yet been 
written to the BI file are forced out. 

2. Newly modified blocks are written to the database 

3. The transaction is marked complete. 
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4. Blocks in the BI file are marked as available for reuse by another trans¬ 
action if there are no current readers requiring read consistency. 

5. Locks held on rows and tables are released. 


THE ROLLBACK WORK STATEMENT 


The ROLLBACK statement "undoes" all operations in the current logical 
unit of work and ends that unit of work. 

Recommended practice is to explicitly end transactions in application pro¬ 
grams using the COMMIT WORK (or ROLLBACK WORK) statement. 
If you do not explicitly commit the transaction and the program terminates 
abnormally, the last uncommitted unit of work will be rolled back. 


INVOKING COMMIT OR ROLLBACK 


Explicit Commits/Rollbacks 


By default, you must commit (or roll back) your transactions in most 
ORACLE products using either of the statements COMMIT WORK or 
ROLLBACK WORK. In some ORACLE products, however, (SQL*Plus 
and SQL, + Calc arc two) you can choose how you want to control your 
transactions. For example, if AUTOCOMMIT is set to ON in SQL+Plus, 
then each DML operation is automatically committed. 


Implicit (Automatic) Commits/Rollbacks 


Certain SQL statements always cause commits at the time they are exe¬ 
cuted. These are DDL statements, and include: 

CREATE TABLE 
DROP TABLE 
CREATE VIEW 
CREATE INDEX 
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If you enter a DDL statement having just entered several DML statements, 
the DDL statement causes a commit to occur, prior to its own execution, 
ending the current unit of work. Then, if the DDL statement executes 
successfully it too is committed. 

Implicit rollbacks also occur. In SQL* *Plus, for example, if 
AUTOCOMMIT is set to OFF so that you have control over when 
commits occur, then certain errors in DML statements will cause rollbacks. 
For example, if you insert several records into a table manually, the at¬ 
tempted insertion of a bad record can rollback prior insertions. 

Errors which cause rollbacks are errors which arc discovered during exe¬ 
cution, such as attempting to insert a duplicate value in an index or an in¬ 
valid number into a numeric column. Syntax errors in a SQL statement 
which are discovered at parse time do not cause automatic rollbacks. 

Automatic rollbacks also occur during deadlock detection or abnormal 
termination. 


THE BEFORE IMAGE FILE 


The before image file (BI file) has the following functions: 

• store database blocks in the event of a rollback 

• store database blocks for read-consistency 

• store database blocks in the event of an IOR CLEAR or CPU failure. 

The Before Image file contains copies of database blocks before they are 
changed, in the event that for some reason the updated version in the da¬ 
tabase is not wanted. For example, if a user changes his mind about a 
transaction because he has insufficent information, he can use the 
ROLLBACK WORK command, which will cause the blocks from the 
BI file to be re-written to the database, effectively undoing that transaction. 
Also, until one user's work is committed, other users querying the same 
table will read blocks from the before image file so that they sec a consist¬ 
ent view of the data. 

The detached process BIW (Before Image Writer) copies the blocks from 
the SGA to the BI file; it is the only writer to the BI file. 

The BI file is implemented as a circular file; entries in the file may be 
overwritten when they are no longer needed. For example, a block entry 
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which was written to support the rollback of a transaction is no longer 
needed when that transaction is committed. 


Monitoring the Before Image File 


One of the screens of the ORACLE Display System (called ODS - see 
“Chapter 4. The ORACLE Display System Utility (ODS)” on page 43), 
the Before Image Screen, can be used to monitor space usage and avail¬ 
ability in the BI file. By comparing the head and tail blocks you can see 
the current status of the BI file. Refer to “The Before Image Display” on 
page 46 for details on interpreting this screen. 


Enlarging the Before Image File 


1 he BI file can only be one file. If a single operating system file can span 
disk packs then a BI file may do so on that operating system. To enlarge 
the BI file, you must first assure that it contains no outstanding trans¬ 
actions. Then you you can replace it with a larger file. 

I o assure that the BI file can be replaced safely, see the following steps, 
hollowing these steps guarantees that the BI file is cleared of any current 
transactions. 

1. Have all users COMMIT their work and log off of ORACLE. 

2. Shut ORACLE down (IOR S). You may skip steps 3 and 4 if the shut 
is successful and the following message appears: 

No active transactions found 

3. Start ORACLE in DBA mode (IOR W DBA). 

4. Immediately shut ORACLE down again (IOR S). 

5. Preserve the BI file to ensure that you can go back to it if necessary. A 
reasonable precaution would also be to make a file backup of the DB file 
at the same time you make a copy of the BI file. 

6. Create a new, larger BI file (using CCF on most systems). 

7. Start ORACLE (IOR W) with the new BI file. (Make sure that the 
INIT.ORA file names the new BI file.) 
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NOTE: If you fail to follow these steps, but you destroy the BI file and 
replace it with a new one, at the next IOR W you may see messages like: 

cannot recover; no before image control block found 

If you have not kept a copy of the old BI file, you will have to rebuild your 
database. 


READ-CONSISTENCY 


The purpose of read-consistency is to guarantee that each user process sees 
data as of the last commit executed before the current DML operation, 
along with DML updates made during the current session. For example, 
a query should not see data that is changing during execution of the query. 
Read-consistency applies to DML statements only: SELECT, INSERT, 
UPDATE, and DELETE. 

The before image file is used to implement read-consistency, by storing the 
blocks necessary to fulfill each SQL statement. A given block in the before 
image file can be used to represent part of a read-consistent state, a rollback 
state, or both. 

If you have long running SELECTS against tables being updated by other 
users, you may have to increase the size of the BI file and increase 
TRANSACTIONS, TABLEJIANDLES, and TABLE ACCESSES. 


ORACLE LOCKS 


This section is of more concern to users on multi-user systems than to us¬ 
ers of single-process systems, such as MS-DOS. Though MS-DOS 
ORACLE acquires locks like any other ORACLE system, no waits or 
deadlocks due to resource contention will ever occur. 

A primary concern of any database management system is how to control 
concurrency, or the accessing of the same data by many users. Without 
adequate concurrency control, data may be updated or changed improperly 
or out of sequence. A common way of controlling concurrent access is to 
use 'locks''. Locks are mechanisms intended to prevent destructive inter¬ 
action between processes (users) in ORACLE. 
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Destructive interaction can be interpreted as interactions which incorrectly 
update data or incorrectly alter underlying data structures (such as table 
or column definitions, indexes, user grants, etc.). 

Locks are used to achieve two important database goals: 

Consistency assure users that the data they are viewing/changing hasn't 
changed out from under them. 

Integrity assure the database's underlying structures accurately reflect all 
changes made to them in the correct sequence. 

ORACLE locking is fully automatic and requires no user intervention. 
However, certain statements permit knowledgeable users to adjust or 
override the default locking. In the following sections, the descriptions of 
those locks which can be explicitly acquired by users include the SQL 
statement used to do so. # 

The general form of the locking statement is: 

LOCK TABLE tablename [, tablename,...] IN 

{ SHARE | SHARE UPDATE | EXCLUSIVE } MODE [NOWAIT] 

A lock can be thought of as something that is "acquired'' by a process 
when the process wants to keep another process from doing something. 

T he lock is "released" when the first process doesn't care anymore. Usually 
a lock is on some "resource" (some object, like a table). 

A process acquires a lock in SHARE mode (S) when it wants to look at 
an object and doesn t want anyone else modifying it. A process acquires 
a lock in EXCLUSIVE mode (X) in order to modify an object and prevent 
any other process from modifying it or locking it in SHARE mode. 


Types of Locks 


Locks in ORACL,E fall into the following categories: 

• Internal 

• Dictionary/Parse (also called DDL Locks) 

• Table/Row (also called DML Locks) 

The first category is of less practical interest to database users, but is dis¬ 
cussed briefly. The latter two categories, however, comprise several differ- 
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ent locks. As they are of significant interest to users, they are discussed in 
more detail. 


Internal Locks 


asyncrcadahcad (ARH) 

audit (AUD) 
before image (BFI) 

cache buffers (CBH) 

control blocks (DCB) 

dictionary cache (DCA) 

enqueues (ENQ) 

framing (FRM) 

processes (PCB) 
table access (TAG) 

temp tables (TMP) 

transactions (ERT) 


Internal locks exist to protect ORACLE'S internal structures (which are 
inaccessible to users). Internal locks which appear in the ORACLE display 
system (ODS) include locks on: 

protects the data structures used to communicate asynchronous read re¬ 
quests from foreground processes to the ARII process. 

protects the audit trail from simultaneous access by multiple users. 

protects disk blocks in the before image file from simultaneous reading and 
writing. 

protects the data structures that track which database blocks are in buffers, 
and how they are being used. 

protects the special system blocks in the database that contain active 
transaction numbers, system constants (such as the next file number to al¬ 
locate), and the table of database file names. 

protects the SGA-resident caches of dictionary data (tables, columns clus¬ 
ters, etc.) 

protects the data structures that keep track of locked tables, rows and other 
resources; also is held during deadlock detection. 

protects the data structures that define recovery points for backout from 
process failures. 

protects the data structures that describe currently-logged-on users. 

protects the data structures that keep track of what tables are in use, by 
whom, and whether (and how) they have been updated. 

protects the cache of temporary tables. Held while temporary tables are 
created or deleted. 

protects the data structures the define the active data manipulation and data 
definition transactions. 
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Types of Locking Compared 


ORACLE RDBMS uses three main types of locks, which are summarized 
in the following sections: 

• Shared locks 

• Exclusive locks 

• Share Update locks 


Share Mode: 


Exclusive Mode: 


Used for: - Querying consistent data. 

Used to prevent: - Others from updating data you're reading 
- Exclusive locks on the table. 

Obtained: Explicitly only: 

LOCK TABLE table-name IN SHARE MODE 

Released: Commit/Rollback 

Log off 

Other termination 

Notes: Share update locks are not prevented, but updates by 

processes holding such locks are prevented. 


Used for: - Changing data and preventing anyone else from chang¬ 

ing it at the same time. 

- Limiting row level locks to one process 

Used to prevent: - Others from updating data you're reading (they can still 
read it) 

- Share, share update, or exclusive locks on the table. 

Obtained: Explicitly: 

LOCK TABLE table-name IN EXCLUSIVE MODE 

Implicitly through any of: 
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INSERT INTO table ... 

UPDATE table ... 

DELETE FROM table 

Released: 

Commit/Rollback 

Log off 

Other termination 

Notes: 

Though other processes cannot get a share lock, they may 
still query data; however, the data may change during 
their queries, though the changed data will not appear in 
their query results. This lock is the only means of guar¬ 
anteeing that only one process is updating a table's data 
at any one time. Because only a single lock is required 
no matter how many rows are modified, using this lock 
minimizes the demands on ORACLE'S lock list. 

Share Update Mode: 


Used for: 

- Reserving the right to update single rows or sets of rows 
for future updates 

- Allowing others to query the table or lock it in SHARE 
UPDATE mode 


Used to prevent: - Others from changing the same rows 


Obtained: 

- Exclusive locks on the table. 

Explicitly: 

LOCK TABLE table-name IN SHARE UPDATE MODE 

Implicitly through: 

SELECT ... FOR UPDATE 

Released: 

Commit/Rollback 

Log off 

Other termination 

Notes: 

Share update mode "reserves the right" to do row locking 
and prevents updates that don't use row locking. Use 
LOCK TABLE ... IN SHARE UPDATE MODE to 
make sure subsequent updates do row locking and are 
able to proceed. 
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Wait Locks 

Wait locks are given if: 

• existing locks prevent the placement of the requested lock. 

• the NOWAIT option is not used when requesting the lock. 

Wait locks are converted to actual locks when the process holding the lock 
rc eases the resource. Multiple locks waiting for the same resource obtain 
the resource on a First In First Out basis (FIFO). If the wait lock being 
converted is a shared lock then all other shared wait locks on that resource 
arc also converted. 

Following sections discuss each individual lock in more detail. 


Dictionary/Parse Locks (DDL Locks) 


In general, DDL locks (caused by data definition SQL statements) lock the 
data dictionary so changes to underlying data structures don't interfere with 
ongoing work. Changes to the structure of database objects (such as the 
definition of tables, columns, clusters, and access privileges) must be kept 
separate from changes to data. Changes to data must be protected simi¬ 
larly; locks for DML operations which protect data are discussed next. 

DDL locks are acquired implicitly at the parse of the OSQL3 call and re¬ 
leased at logoff, when the cursor is reused, or the cursor is closed. (Refer 
to the programmatic interface guides -such as Pro*FORTRAN User's 
Guide- for a discussion of ORACLE calls including OSQL3.) Dictionary 
locks are all acquired automatically by ORACLE; they cannot be acquired 
explicitly by a user. 

There are three types of dictionary/parse locks: 

• The Dictionary Operation Lock 

• Dictionary Definition Ixicks 

• Table Definition Locks 


The Dictionary Operation Ixick 

T his lock locks the data dictionary during any operation affecting the data 
dictionary, guaranteeing that only ONE dictionary operation occurs at a 
time. Therefore, only one dictionary operation lock may exist at any one 
time and the lock is always exclusive. Examples of operations affecting the 
data dictionary include CREATE or DROP TABLE, INDEX, VIEW, 
CLUS'I ER, and when a table acquires another data or index extent. 
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Note that the dictionary tables are not locked for the entire duration of the 
operation; they are locked only while they are being directly updated by 
ORACLE. For example, the command CREATE INDEX locks the dic¬ 
tionary tables while new rows are added describing the index, not while the 
index itself is being built. 

This lock appears in ODS as: 

DDL ... 10000 ... 0 X 

See the NOTE at the end of the next section for additional information 
regarding dictionary definition and dictionary operation locks. 

If a lock is not available when a process requests it, the requesting process 
will wait until it is available. 

Dictionary Definition Locks 

There may be several dictionary definition locks at any one time, and they 
may be owned shared or exclusive. 

The dictionary definition lock is owned exclusively by a process doing a 
DDL or DCL command. It prevents parsing during user-originated dic¬ 
tionary operations. This prevents the structure of a table (or its existence) 
from being changed at the same time the dictionaries are being queried. 

An exclusive dictionary definition lock appears in ODS as: 

DDL ... 20000 ... 0 X 

Dictionary definition locks are owned shared by users who are parsing 
queries or DML statements (such as INSERT, UPDATE, or DELETE). 
A shared dictionary definition lock appears in ODS as: 

DDL ... 20000 ... 0 S 

by users who are parsing statements. 

NOTE: There is only one exclusive dictionary definition lock, and only 
one dictionary operation lock, and only one of each can occur at any one 
time. A user obtaining a dictionary definition lock will almost always 
shortly thereafter get a dictionary operation lock (as in CREATE TABLE). 
However, a user with a dictionary operation lock will not necessarily re¬ 
quire a dictionary definition lock (as when a table obtains another data 
extent). 

If a lock is not available when a process requests it, the process will wait 
until it is available. 
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Table Definition I^>cks 


Table definition locks may be owned shared or exclusive. 

They are owned exclusively by users modifying tables definitions. Exclu¬ 
sive table definition locks appear in ODS as: 

DDL ... partition ... rba X 

where partition and rba refer to a particular table. 

Table definition locks are owned shared by users referencing tables in a 
SQL statement. Every active SQL statement will have shared locks; these 
locks are probably the most common lock. Shared table definition locks 
appear in ODS as: 

DDL ... partition ... rba S 

where partition and rba refer to a particular table. These locks prevent any 
changes to the dictionary entries for a table while there is an active SQL 
statement against the table. For example, while a table is referenced in a 
parsed SQL statement, no dictionary operation affecting that table can oc¬ 
cur (such as ALTER TABLE, CREATE or DROP INDEX, or DROP 
TABLE). Processes attempting such data definition commands against a 
table referenced by an active SQL statement will receive an error message, 
like: 

data definition operation and resource being used 

If you receive this message, simply try the operation again later. 


Table/Row Locks (DML Locks) 


Unlike dictionary /parse locks which lock structures, these locks exist to 
guarantee data consistency through concurrent transactions. Locks can 
occur at either the table or row level. Most DML locks can be acquired 
explicitly by a process, or implicitly, when necessary, through certain SQL 
statements. TABLE locks owned by a process are released when that 
process: 

• commits 

• logs off or is terminated 

• rolls back. 
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ROW locks owned by a process are released only when the process: 

• commits 

• logs off or is terminated. 

Note that row-level locks are NOT released when a process rolls back. 
There are two types of table locks: 

LOCK TABLE tablename [,tablename] IN SHARE MODE [NOWAIT] 

LOCK TABLE tablename [,tablename] IN EXCLUSIVE MODE [NOWAIT] 

Multiple tables may be locked in either Share Mode or Exclusive Mode. 

In addition to Share Mode and Exclusive Mode, there is a third mode, 
Share Update Mode, which is discussed under Row-Level Locking. Use 
the NOWAIT option to avoid waiting if a lock is temporarily unavailable. 
There is one type of row lock: 

SELECT ... FROM tablename FOR UPDATE OF colname [NOWAIT] 


SHARE Mode Table Locking 

A share lock on a table is only obtained explicitly, and is used to prevent 
other users from updating the locked table, though not from reading it. 
The primary purpose of this lock is to keep data from changing between 
two queries. The syntax is: 

LOCK TABLE tablename in SHARE MODE [NOWAIT] 

Tables locked in share mode show two lines in ODS: 

DML partition rba S 

DML 10000+partition rba S 

A share lock is released when a process commits or rolls back, or logs off 
or is terminated. 

EXCLUSIVE Mode Table Locking 

These locks can be obtained implicitly using the DML statements IN¬ 
SERT, UPDATE, and DELETE, or explicitly using the statement: 

LOCK TABLE tablename IN EXCLUSIVE MODE [NOWAIT] 
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An exclusive lock prevents other users from obtaining a share lock or from 
doing any DML transactions such as INSERT, UPDATE, or DELETE, 
which would obtain an EXCLUSIVE lock. Other processes may query the 
table; however, they are not guaranteed current data. This lock is the only 
method of guaranteeing that only one process may change a table's data. 

If a particular updating transaction requires several tables, using exclusive 
locks may reduce the likelihood of a deadlock. 

Exclusive locks appear in ODS as: 


DML partition rba X 
example: DML.1_124d X 


SHARE UPDATE Mode (Row-Level Locking) 

While table locks assure consistency, they reduce concurrency. Row-level 
locks, on the other hand, both guarantee consistency and improve con¬ 
currency. Row-level locks occur in SHARE UPDATE MODE (not to 
be confused with SHARE mode, which is used in table locking.) 

Row-level locking assures that the rows you wish to change are not 
changed between the time you fetch the row and update it. Consider the 
following three scenarios (A, B, and C) of updating a row: 



TABLE-LEVEL ROW-LEVEL 

ACTION: 

USER: A B C 

Fetch row to 
at it 

look fetch fetch, (w/ fetch (select 

SHARE lock) for update) 

Look at row 

• 

Update 

update (automatic EXCLUSIVE table lock) 

Commit 

commit (EXCLUSIVE lock is released) 


In scenario A, no locking occurs until the update, and therefore the row 
can be changed and committed by another user before user A makes his 
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change. The benefits of increased concurrency simultaneously raise the risk 
of updates on already updated data. 

Scenario B eliminates the possibility of B updating data that someone else 
has just changed, but it reduces concurrency, because user B has a shared 
lock on the entire table before he obtains the exclusive lock for update. 
The gain is reliability at the price of concurrency. 

In scenario C, by using a row lock (using SELECT ... FOR UPDATE) 
both reliability and concurrency are optimized. The row lock assures that 
the row will not change while C is looking at it, and the table is only locked 
exclusively during the actual update. 


Row-level locking is the same as Share Update Mode 

To be precise, if you invoke row-level locks with SELECT ... FOR UP¬ 
DATE, then you are in Share Update mode (using both row-level locks 
and Share Update mode); you can, however, be in Share Update mode yet 
have no row-level locks. A user can request Share Update mode for a table 
in two ways — using SELECT ... FOR UPDATE as in Query 1, or by 
explicitly invoking Share Update mode as in Query 2: 


Query 1: 

SELECT EMPNO, ENAME 
FROM EMP 

WHERE EMPNO = 7839 
FOR UPDATE OF SAL 


Query 2: 

LOCK TABLE tablename 
IN SHARE UPDATE MODE 


All tables whose columns appear in the FOR UPDATE clause are locked 
in share update mode. NOTE: The prior selection of ROWID to acquire 
a row-level lock is required in Version 4 ORACLE RDBMS but is not 
required in Version 5 ORACLE RDBMS. However, including it in the 
SELECT list is useful, especially to assure that the ROWID has not 
changed since you last accessed it. 


Why Use Share Update Mode? 

The main reason for using share update mode is because other users are 
using row-level locking (as in SQL* Forms), and you do not need or wish 
to use the SELECT...FOR UPDATE statement. You might use the 
LOCK TABLE ...IN SHARE UPDATE MODE if you want to make 
your program clear; because you're inserting (as contrasted to updating or 
deleting existing rows) or because your updates don't require you to iden¬ 
tify exact rows, as in: 


UPDATE EMP SET SAL = SAL *1.1 WHERE JOB = 'PROGRAMMER 1 
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If any user has a table locked in share update mode, any other user must 
also be in that mode in order to perform an insert, update, or delete on the 
same table (or he must wait for the share update lock to be released). 

Even in share update mode, no two users can actually update a table at the 
same time; at the actual update (or other DML operation), the table is 
locked exclusively until the transaction commits or rollsback. 

Row locks are always exclusive. 

These locks appear in ODS as: 

SELECT...FOR UPDATE: 

ROW kba prn X 

example: ROW_9228...10001 X 

where KBA is the hexadecimal kernel block address and pm is the partition 
and row number in the logical block. In the following example, 9228 is the 
kernel block address, the partition is 1, and the row is 0001. 

SHARE UPDATE MODE: 

during SELECT FOR UPDATE or LOCK ... SHARE UPDATE 
DML partition rba S 

example: DML.1_ 1243 S 

during update time: 

DML 10000 + partition rba X 
example: DML...10001_ 1243 X 


Locking in SQL*Forms 


SQL+Forms works in SHARE UPDATE mode, because row-level locks 
are particularly useful in applications where a reasonable time may pass 
after a particular row has been fetched and updated on the screen but be¬ 
fore the COMMII key is pressed. The use of row-level locks guarantees 
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that the row is not changed "out from under" a user without a warning. 

If a requested row is currently locked, the user sees a message like: 

Attempting to reserve record for update (x to abort) 

where x is the specific operating system's interrupt sequence. Then 
SQL+Forms rerequests the lock on behalf of the user, waiting until it is 
available. 

Changes to base table data are not written until the user fully specifies all 
changes and presses COMMIT. If a rollback occurs, the locks are not re¬ 
leased in the expectation that the user will change some values and retry 
COMMIT. 

SQL*Forms does not execute LOCK statements for triggers. If the trigger 
is against the base table for the current block and if rows have been updated 
or deleted, then the table is already locked. However, if the trigger is 
against a non-base table, then your trigger should consist of at least two 
SQL statements - the first locking the non-base table in Share Update 
mode - to avoid the possibility of long waits. 


;field name: 
post update 
;SQL> 

lock table bonus in share update mode 

/ 

;msg 

some message here 
;must value exist 

y 

; SQL> 

update bonus set bonus = &sal * 1.15 where ename = &ename 

SQL’Tlus users wishing to update tables in use by SQL+Forms should also 
use Share Update mode. 


Restrictions on Locking 


Though it is never necessary for a user to explicitly lock any table, some 
users may wish to do so for a number of reasons (such as experimenting 
with ODS or avoiding a potential deadlock). You can lock a table if you 
own the table, have SELECT privileges on it, or have DBA authority. 
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No user, regardless of authority, can explicitly lock any ORACLE data 
dictionary table. 

Deadlock Detection 


Deadlocks can occur in multi-user systems when each process in a group 
is waiting to access a resource (lock a table) that another process has al¬ 
ready locked. I his creates a deadlock situation, because no further work 
can be done by those processes. ORACLE detects the deadlock and rolls 
back the transaction with the least amount of work completed (based on 
the number of modified database blocks). After the rollback, the locks that 
process held are released and the other processes can continue their work. 

In many cases, deadlocks can be avoided if processes accessing the same 
tables lock those tables in the same order as each other, either through im¬ 
plicit or explicit locks. 

General Locking Recommendations 


In general, the goal is to reduce contention for the same resources to 
maximize throughput. More specifically, it is desirable to minimize the 
time between the first update and a commit or rollback. The following 
recommendations will help: 

1. For UPDATE and DELETE operations where there may be some time 
before commit, consider locking the records of interest so that they will 
not be changed until after you have made your changes, and deferring 
the changes until just before commit. 

2. If there may be other processes updating using Share Update mode (as 
in SQL + Forms), use SHARE UPDATE mode, rather than SHARE 
mode or implicit locking, so as to maximize concurrency and allow other 
processes to use row-level locking. 

3. When possible, design applications so that all processes of a table access 
it in the Share Update mode; this will improve concurrency. 

4. Avoid modifying the underlying data structures (tables, columns, in¬ 
dexes, clusters, views, synonyms) during the heaviest periods of applica¬ 
tions use (for example, entering or querying data). 
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CHAPTER 10. TUNING A SYSTEM FOR PERFORMANCE 


This chapter describes the purpose and use of indexes and clusters, the two 
most important performance tools. It also covers context space and the 
performance implications of the wording of various SQL statements. 

A single user can take numerous actions to improve his own ORACLE 
transactions, independent of other users. Among his most valuable tools 
are indexes and clusters. 

1 here are also steps a DBA or applications designer can take to improve 
ORACLE performance, specifically for multiple and concurrent users. 
These steps include adjusting INIT.ORA parameters, setting database de¬ 
faults, etc. 

Finally, there are general operating system considerations which may help 
ORACLE performance; more details on this type of tuning are found in 
the Installation and User s Guide for the individual operating systems. 

NOTE: The information contained in this chapter pertains to the current 
version of the ORACLE RDBMS at the time of writing; this information 
is subject to change in future releases. 


SINGLE USER TUNING 


Performance gains a single user can achieve generally depend upon how 
his data are defined and stored. Given the same set of data to be stored, 
the sets of tables which may define it are unlimited, but the set of tables 
actually used can serve to highlight the relational advantage (if done well), 
or lead to bad performance and design traps (if done poorly). A good 
understanding of relational theory and its practical application (both of 
which are beyond the scope of this manual), will go a long way toward 
helping designers and users achieve the flexibility and high performance of 
a well-designed relational database application. 
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Aside from proper table design, users can notice substantive performance 
gains by using the indexing and clustering features. Experienced users may 
occasionally notice differences in performance by reworking some SQL 
queries, as there are often at least two ways to request the same data. 


INDEXES 


Indexes have two primary purposes: 

Speed execution Just as the index in this manual helps you locate information you want 

faster than if you had no index, indexes in ORACLE offer the ORACLE 
RDBMS a faster means of locating the data users need. Indexes are the 
primary means of reducing disk I/O. The use of indexes is strongly re¬ 
commended to improve performance on joins of multiple tables. 

Guarantee uniqueness Indexes can guarantee that data in one field, or a combination of fields, is 

unique for every record in a table. For example, an index can guarantee 
that every value entered for a social security number is unique; it can do 
the same for the combination of area code and phone number. 

Indexes, Keys, and Foreign Keys 


Note the distinction between indexes and keys. Indexes are actually im¬ 
plemented by SQL, to provide the two features just mentioned. Keys, on 
the other hand, are a logical idea. A key is a column (or combination of 
columns) which can be used to uniquely identify a row. A foreign key, also 
an idea and not specifically addressed by SQL, is a column in one table 
which is a key in another table. Foreign keys are very useful when com¬ 
bining data from multiple tables, using joins; in the following example, 
DEPTNO is a foreign key in table EME, while it is a key (and presumably 
indexed) in table DEPT, because each DEPTNO uniquely identifies one 
row in that table. 

SELECT ENAME, DEPTNO, DNAME 
FROM EMP, DEPT 

WHERE EMP.DEPTNO = DEPT.DEPTNO 

ORACLE neither requires nor enforces that keys be present. However, the 
use of indexes is highly recommended to achieve better performance, and 
generally one of the first indexes to be created on a table is the index on the 
column or columns which form the key. 
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This section discusses the creation and use of indexes, and describes the 
different types of indexes and their relative advantages. 


Creating Indexes 


The owner of a table can create indexes on it. Any ORACLE user who 
has been granted INDEX access on that table can also create an index. 
Indexes on a table are used when possible for a SQL statement, regardless 
of who created the index. 

The general syntax for creating indexes is shown in Eigure 32. 


CREATE [UNIQUE] INDEX index_name ON tab1e_ .name 
columnl_name [,column2_name, column3 name] 
[{SYSSORT | NOSYSSORT}] 

[ PCTFREE=n] 

[{COMPRESS | NOCOMPRESS}] 

[ ROWS = rowcount ] 


Figure 32. CREATE INDEX Syntax 

SYSSORT/NOSYSSORT SYSSORT is the default and should always be 
used. It invokes the ORACLE sort/merge routine; 
NOSYSSORT means to not use the ORACLE sort, but rather 
use index insertion algorithms. NOSYSSORT should only be 
used on the instruction of Oracle Corporation personnel. 

ROWS This option is ignored in Version 5. 

PCIFREE=n PCTEREE indicates how full the B*-tree leaves will be 
during initial index creation; a value of 10 to 15% is reasonable 
if new rows will be inserted. Default is 10. 

COMPRESS/NOCOMPRESS Indicates whether index data will be 

compressed or not. Default is COMPRESS. See “Compressed 
and Noncompressed Indexes” on page 156 for a description of 
both types of indexes. 

When the CREATE INDEX command is entered, the column(s) to be 

indexed are ordered and for each row, the ROWID saved. Thus, for the 

statement: 
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CREATE INDEX IN_EMP_EMPNO ON EMP(EMPNO) 

a sort is performed for EMPNO and ROWID for all existing rows, and the 
BMree index is loaded, from the bottom up. (See “The Internal Structure 
of Indexes” on page 163 for a brief description of the internal structure of 
B + -tree indexes.) 

Once created, an index is automatically maintained and used by ORACLE. 
For example, changes to the data, such as adding new rows or deleting 
rows, are automatically incorporated with no additional effort by the user. 

A table may have any number of indexes; however, the more indexes the 
more overhead is incurred as data in the table is updated. Thus, you may 
have to examine a tradeoff between speed of lookup for queries versus 
speed of accomplishing updates. For example, if a table is read only, more 
indexes may be useful, but if a table will be heavily updated, fewer indexes 
may be reasonable. 

Normally an index is created after data is in the table (for example, it is 
more efficient to load a table using ODL before creating any indexes on the 
table). If the index is created first, before loading data, then the index must 
be updated every time a row is inserted. An exception can be made, at the 
expense of performance, if you want to assure that a particular value is 
unique for every row loaded, in which case a unique index can be created 
on the column(s) desired to be unique. 


Concatenated Indexes 


A concatenated index is an index which is created on more than one col¬ 
umn in one table. Concatenated indexes arc the only way to enforce 
uniqueness across several columns (as in the combination of area code and 
phone number). If it takes more than one column to uniquely identify any 
row in a table, you will probably want to create a concatenated index on 
those columns. Concatenated indexes can also speed retrieval of data re¬ 
turned by SQL statements with several criteria in the WHERE clause. 

Up to 16 columns may be indexed by a single index, subject to the limit 
on the number of characters which may be indexed. The maximum 
number of characters in any index (concatenated or not) is 240 characters 
including 1-byte separators, which are used to distinguish the indexed col¬ 
umns. 1 he actual width is determined by summing the width of each col¬ 
umn to be indexed and adding the number of columns to be indexed minus 
1 (to account for the separators). 

An example of creating a concatenated index follows: 
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CREATE UNIQUE INDEX IND_VEND_ID 
ON VENDORS (VEND_ID, PART_NO) 

This index would be reasonable to build if queries such as: 

SELECT * 

FROM VENDORS 

WHERE VEND_ID = '1292' 

AND PART_N0 = 457 

were executed often. 

The order in which columns are named in the CREATE INDEX com¬ 
mand need not correspond to the order they appear in the table definition. 
However, performance can be affected by the order chosen. In general, you 
should put the column expected to be used most often first. 

A concatenated index will be used to speed retrieval on any query using the 
leading portion of the index. Queries with WHERE clauses using only the 
first column(s) of a concatenated index will also note a performance gain. 
For the following examples, assume the following concatenated index has 
been created: 

SQL> CREATE INDEX INDNAME_CITY_STATE ON 
EMPLOYEE (LAST_NAME, CITY, STATE) 

In the first example, because the WHERE clause names the same three 
columns as were named in the index, the index will be used to speed re¬ 
trieval: 

SELECT ... 

FROM EMPLOYEE 

WHERE LAST_NAME = 'SMITH' 

AND CITY = 'FREDERICK' 

AND STATE = 'MD' 

If only the first column of the index is used in the WHERE clause, the 
index will still be used but the index won't be as selective as in the previous 
example. 

SELECT ... 

FROM EMPLOYEE 

WHERE LA$T_NAME = 'JONES' 

AND STATE = 'VA' 
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In the next two examples, the index cannot be used, because the WHERE 
clause does not name the fust column in the index: 

SELECT ... 

FROM EMPLOYEE 

WHERE CITY = 'BLACKSBURG' 

AND STATE = 'MD' 

SELECT ... 

FROM EMPLOYEE 
WHERE STATE = 'DC' 

The use of concatenated, noncompressed indexes can be a powerful per¬ 
formance tool — by allowing certain queries to be satisfied by reading only 
index blocks and not data blocks. 


Compressed and Noncompressed Indexes 


Compressed Indexes 

By default, indexes are created compressed. 'That is, the actual index data 
is stored using both forward compression and rear compression. The por¬ 
tion of an index value which is stored is that part which makes the value 
unique from the values immediately before and immediately after it. 
figure 33 on page 157 demonstrates compressing index values. 

The advantage of compressed indexes is that storage is substantially re¬ 
duced, which leads to a shallower B + -tree (fewer levels) and thus less I/O. 
However, there is a processing cost associated with performing the com¬ 
pression, and decoding compressed values upon retrieval. For example, if 
the column for the values shown in Figure 33 on page 157 were defined 
as CHAR(IO), then ORACLE can reconstruct those keys only as far as: 

JOHNS????? 

JOHNSTO??? 

JOHNSTOW?? 

JOHNT???? 

but to retrieve the actual data values ORACLE must go the the table's 
actual data blocks. ORACLE may internally fetch records that might sat¬ 
isfy a query based on the compressed key only to sec that the actual row 
value does not satisfy the query. 
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To index the values: 


JOHNSON 



JOHNSTON 



JOHNSTOWN 



JOHNTON 



FORWARD COMPRESSION: 


How many characters at beginning of each 

key are the same as the preceding key? 

Key 

Count of Same 

Result: Forward Compression Count 


Characters: 

and remaining key: 

JOHNSON 

0 (first key) 

0 JOHNSON 

JOHNSTON 

5 

5 TON 

JOHNSTOWN 

7 

7 WN 

JOHNTON 

4 

4 TON 

REAR COMPRESSION: 


How many characters at end of each key are the same as the preceding key? 

Key 

Result of 

Result of 


Forward Compression 

Rear Compression 

JOHNSON 

0 JOHNSON 

0 JOHNS 

JOHNSTON 

5 TON 

5 TO 

JOHNSTOWN 

7 WN 

7 W 

JOHNTON 

4 TON 

4 T 

ACTUAL INDEX 

VALUES AS RESULT OF FORWARD AND REAR COMPRESSION: 

Key 

Forward Compression 

Key Remaining 


Counter 

Length Key Data 

JOHNSON 

0 

5 JOHNS 

JOHNSTON 

5 

2 TO 

JOHNSTOWN 

7 

1 W 

JOHNTON 

4 

2 T 


Figure 33. Example of Forward and Rear Compression on Index Values 


Non com pressed Indexes 

You can specify that an index be created without any compression by 
specifying the NOCOMPRESS option in the CREATE INDEX com¬ 
mand. Because noncomprcssed indexes store the entire index data value, 
they can return results sooner, in some cases, than compressed indexes. 
Judiciously chosen, noncompressed, concatenated indexes can be very 
useful for this reason. Using noncomprcssed indexes (concatenated or 
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single-column), some queries can be resolved directly in the index without 
even reading data blocks. This is true when every column referenced any¬ 
where in the SQL statement is in the noncompresscd index and a WHERE 
clause is used. For example, if there is a noncompressed index on 

ENAME, then both the following queries can be resolved using the index 
only: 


SELECT ENAME 
FROM EMP 

WHERE ENAME LIKE 'N%S' 


SELECT COUNT (ENAME) 
FROM EMP 

WHERE ENAME = 'CHRIS' 


Noncompressed indexes also save time because key decompression during 
lookup is avoided. However, because all the index data is stored, non¬ 
compressed indexes obviously require more space. Whereas compressed 
indexes require approximately 10 bytes per entry, noncompressed indexes 
require about 17 bytes per entry, plus the key value, see “Calculating the 
Number of Index Segments” on page 113. 


Writing SQL Statements to Take Advantage of Indexes 

There are two primary way ORACLE accesses data in a database table: 

• using a full table scan 

• using index(es). 


In almost every instance the use of an index is preferable to using a full- 
table scan, because most SQL statements arc used to extract desired rows 
of data from tables rather than use all rows in a table. DML statements 
(in particular SELECT, UPDATE, and DELETE) often contain clauses 
identifying which records should be included or excluded; for example, 
update the salary for all employees in development, or select birthdays of 
all women. 

A full table scan is preferable when you know in advance that more than 
about 25 percent of the records in the queried tables will be selected and 
so using the index to find all of the records only adds overhead. 

An index can be used if: 

• it is referenced in a predicate clause. A predicate is each portion of se¬ 
lection criteria used to include or exclude rows from a result. For ex¬ 
ample, the following WHERE clause contains two predicates: 
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WHERE DNAME = 'DEVELOPMENT 1 
AND SEX != 'FEMALE' 


• the indexed column is not modified by a function or arithmetic opera¬ 
tion. 

An index will be used if the optimizer decides it is appropriate (several fol¬ 
lowing sections describe the choices ORACLE makes based on the set of 
circumstances, many of which a user can control). 

An index will not be used if: 

• there is no WHERE clause 

• the predicate modifies the indexed column in any way (via a function 
or arithmetic expression) 

• the search is explicitly for records with NULL or NOT NULL values in 
the indexed column (that is, the predicate contains either IS NUL,L or 
IS NOT NULL). 

If the column must be modified to meet the selection criteria, as in the 
following examples, an index cannot be used: 

SELECT * FROM EMP 
WHERE SAL * 12 = 24000 

WHERE SAL + 0 = 500 

WHERE ''||ENAME = ' Smith' 

WHERE SUBSTR(ENAME, 1,1) = 'S' 

One exception exists to the "indexed column cannot be modified" rule - 
if the query includes an expression containing: 

{ MIN | MAX } ( < col > { + | - } < constant> ) 

and no other columns, as in: 

SELECT 2 * MAX (SAL+1) FROM EMP 

The same query can be worded in different ways to use or avoid the use 
of an index. Eor the following examples, assume that the column 
HIREDATE is defined as DATE and has a nonunique index. The query 
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SELECT * 

FROM EMP 

WHERE TO_CHAR(HI REDATE, 'Month dd, yyyy') 

= 'January 14, 1986' 

modifies the HIREDATE column with the TO CHAR function; the index 
on IIIREDATE is not used. 

Whereas, in the query: 

SELECT * 

FROM EMP 

WHERE HIREDATE = 

T0_DATE('January 14, 1986', 'Month dd, yyyy') 

the constant (January 14, 1986) is converted to a date, and so ORACLE 
will use the index to do the search. 

In general, it is better practice to make constants used as selection criteria 
match the datatypes defined for the table. 

Following sections discuss how to write SQL statements to use or avoid 
use of indexes, and how to determine which indexes should be used. 


Single Indexes 


In a simple query on one table, where a predicate refers to an indexed col¬ 
umn, once ORACLE has identified the index and decided it will use it, it 
searches (rather than scanning) the index for the value(s) of interest. (A 
scan is a sequential lookup through a table, whereas a search is a search 
using an index.) Thus, both a full table scan and an index scan are avoided. 
For the following query: 

SELECT EMPNO, ENAME 
FROM EMP 

WHERE JOB = 'CLERK' 

once ORACLE finds that the JOB column has an index (either unique, 
which is unlikely in this case, or nonunique), it will search for the desired 
value in the index ( CLERK'), and return all records with the value 
CLERK'. 


160 / The ORACLE Database Administrator's Guide 















Indexes and Null Values 


When possible, define columns of tables as NOT NULL,; this will allow 
index use on a slightly greater number of queries. 

Indexes are not used if the predicate contains either of the phrases: IS 
NULL or IS NOT NULL. However, if you are interested in obtaining the 
not null values (but not the null values), you can usually write the SQL 
statement so it will use an index. "This can be done to return rows where 
the column has a value, not the columns where the value is null. For ex¬ 
ample, say we wanted to see all employees who make a commission (whose 
commission is NO F NULL), we could use cither of the queries: 

Query 1: Query 2: 

SELECT * FROM EMP SELECT * FROM EMP 

WHERE COMM IS NOT NULL WHERE COMM >= 0 

Assuming an index exists on the COMM column, it is not used for Query 
1, but it would be used by Query 2 to get the results without performing 
a full table scan. However, if most records in the EMF table do have a 
value for COMM, then Query 1 is preferred. Query 2 is only preferred if 
most records have a null value for COMM. 


Multiple Indexes on One Table 


A query with two or more predicates can use multiple indexes if: 

• the indexes are nonunique column indexes 

• the predicates are equalities 

• the predicates are on the same table. 

Data returned from each index's search is "merged" with previous results 
to obtain the final result. Multiple indexes are not used for "bounded range 
and equality" predicates, such as: 

SELECT * 

FROM EMP 

WHERE JOB = ’MANAGER 1 
AND DEPTNO > 10 

Rather, the index for the equality will drive the query. 
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Choosing Among Multiple Indexes 


In queries with multiple indexes available but no clear preference, 
ORACLE chooses the driving index based on the types of index (that is 
-- compressed/noncompressed, unique/nonunique) and the column char¬ 
acteristics. 

When both a unique and nonunique index are available, ORACLE uses 
the unique index and ignores the nonunique index, thus avoiding the 
merge". I-or example, assuming a unique index on EMPNO and a non¬ 
unique index on SAL, in the following query: 

SELECT ENAME 
FROM EMP 

WHERE SAL = 3000 
AND EMPNO = 7902 

0 R ACLE wm use only the index on EMPNO. If a row is found with 
EMPNO 7902, the actual SAL field is examined to see if it is 3000 rather 
than using the index on SAL. 

In ORACLE Version 5, only five indexes are merged. If more than five 
criteria exist in the SQL statement, as many as five indexes are merged, but 
alter five all remaining data is "manually" checked to extract records meet¬ 
ing the remaining criteria. 


Suppressing the Use of Indexes 


indexes that are appropriate are merged, it is occasionally possible 
that the use of an index can decrease performance. Or, since up to five 
indexes are used in a query, if you are writing a SQL statement with pred¬ 
icates referencing more than five indexed columns, then you may wish to 
suppress the use of the least valuable" (least selective) indexes. 

To suppress index use, simply use a "dummy" function or expression with 
the column whose index you do not want to invoke. Typically you would 
either add a zero to a numeric column or concatenate a null string to a 
character column, as in: 

SELECT ENAME, DEPTNO, SAL 
FROM EMP 

WHERE DEPTNO + 0 = 20 
AND ENAME = 'SMITH' 
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For additional information about how to avoid indexes, refer to “Writing 
SQL, Statements to Take Advantage of Indexes” on page 158. 

The VALIDATE INDEX Command 


You can use the VALIDATE INDEX command to check a particular in¬ 
dex for consistency. You can also validate an index created by another 
user. The syntax is: 

VALIDATE INDEX Indexname [ON tablename] [ WITH LIST] 

For example: 

VALIDATE INDEX IN_EMPN0 
VALIDATE INDEX ENAME ON SCOTT.EMP 

The WITH LIST option is used to create a trace file and should be used 
only at the request of ORACLE support personnel. If you get any message 
other than: 

Index validated. 

then the index is not valid. This is an abnormal condition which should 
be reported. After reporting the error, you can drop and re-create the in¬ 
dex. 

Index validation uses the index as its source and can detect: 

• invalid index formats, or bad index structure 

• index entries which do not match row data, or bad index data (as when 
an index entry has no matching row). 

Index validation does not detect actual data rows which do not have cor¬ 
responding index entries. 

The Internal Structure of Indexes 


All indexes in an ORACLE system are stored in B+-Tree structures. 
Figure 34 on page 164 illustrates the structure of a B*-Tree index. 
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contents of 
leaf Index block: 



BLAKE - ROWID 
CLARK - ROWID 
FORD - ROWID 


Figure 34. Example of a B*-Tree Index 


The upper blocks of a BMree index contain index data values used as 
pointers and the addresses of lower level index blocks. The lowest level 
index blocks contain every indexed data value and its corresponding 
ROWID, to locate the actual row. For a unique index, there will be one 
ROWID per data value. For a nonunique index there can be any number 
of ROWIDs per data value. Indexes are sorted by both the index value 
and ROWID. 

Advantages of the BMree structure include: 

• Because all branches of the tree are the same depth, retrieval of any re¬ 
cord from the physical beginning or physical end of the table takes ap¬ 
proximately the same amount of time. 

• Because all nodes of the BMree are more than half-full, storage space is 
continually reclaimed and allocated. 
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• Record insertions and deletions are efficient, maintaining key order for 
fast interactive or batch retrieval. 

Though there is some operational overhead spent keeping the B*-trce index 
balanced, it is minimal compared to the savings in retrieval time. Most 
databases spend the majority of time doing data retrieval as opposed to 
data manipulation; a B*-tree is fast for retrieval of records either sequen¬ 
tially or singly. 

Other advantages of indexes in ORACLE arc: 

• Indexes are logically and physically independent of the data and can be 
dropped and recreated anytime without affecting an application. 

• indexes are maintained automatically 

• retrieval performance remains almost constant even as table grows 
(number of records increases). 


CLUSTERS 


What are Clusters? 


Clusters are an alternate method of storing data in an ORACLE database, 
which have no effect on the SQL statements used to access that data. To 
identify data which may be better stored in clustered form than stored 
non-clustered, look for tables which have one or more columns in common 
(usually key columns), and tables which arc frequently accessed together 
(in join operations). By clustering such tables, you can speed retrieval time 
for queries by shifting the retrieval from index-oriented to physical retrieval. 

The purpose of clustering is to store data physically close which is often 
logically queried together. This accomplishes several goals: it reduces 
search and compute time because data is stored closer together and it re¬ 
duces storage because the data common to both tables is stored only 
once. For example, if a cluster's key was ORDER NO, and on the average 
there were 30 items per order, then rather than storing ORDER NO 30 
times (once for every item ordered), it would be stored just once. 

It is important to note that the existence of clusters, once they are created 
and the data is loaded, is transparent to users and to applications; users 
reference clustered data exactly as they do non-clustered data. They need 
not even know which data is clustered or is not. 
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Logical Format of Clustered Data Blocks 


The logical format of a clustered block is shown in Figure 35. Note that 
the overhead for a clustered block is 44 bytes for each physical block and 
32 bytes for each logical block. 1 here may be several logical cluster blocks 
per physical block (sec “Determining the Logical Block Size” on page 
168). If there's one logical block per physical block, the overhead is 76 
bytes (44 + 32, as in the non-clustered case). (See "Logical Format of 
Non-Clustered Data Blocks” on page 103 for a discussion on non-clustered 
data.). If there are two logical blocks per physical block, the overhead is 
108 bytes per physical block (44 + 32 + 32) and so on. 



Figure 35. Clustered Logical Data Block Format 

The Cluster Key 


The cluster key is formed by the column(s) named in the CREATE 
CLUSTER statement; it may be composed of one or multiple columns. 
The cluster key is stored once per logical cluster block. It also appears in 
every chained cluster block (which somewhat simplifies the cluster¬ 
building/scanning algorithms). 
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The cluster key is stored in blocks allocated by the INDEX segments 
specified in the space definition in effect for the cluster creation. Because 
ORACLE automatically builds and maintains an index on the cluster key, 
you need not use CREATE INDEX to build an index on the columns 
which form the cluster key. However, it is reasonable to manually build 
an index using the cluster key if you want to make it a part of a concat¬ 
enated key, or you want to make it a unique index for one of the tables in 
the cluster. 

The cluster key can be updated. That is, the data in columns of a table 
which correspond to the cluster key can be updated. Since the placement 
of data depends on the cluster key, changing the cluster key for a record 
causes the physical relocation of the record. 


Creating Clusters 


The syntax for creating a cluster is: 

CREATE CLUSTER cluster_name 

( cluster_keyl datatype, c1uster_key2 datatype, ...) 

[ SPACE space_name ] 

[ SIZE 1ogical_block_size ] 

[ COMPRESS | NOCOMPRESS ] 

where: 

SPACE references a space definition, just as for CREATE TABLE. 

COMPRESS/NOCOMPRESS indicates whether the cluster key is built 
compressed or non-compressed. 

SIZE refers to the requested logical block size, which is adjusted by 
ORACLE to the actual logical block size. If SIZE is not speci¬ 
fied, the operating system's ORACLE block size minus physical 
block overhead is the default. Sec “Determining the Logical 
Block Size” on page 168 

The following rules exist for creating clusters: 

• No more than 32 tables or 16 columns may be clustered. 

• Cluster key in table must match cluster key in cluster (both the datatype 
and size must match) and at least one clustered column in each table 
must be NOT NULL. 

• The cluster key may be multiple columns. 
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Determining the Logical Block Size 

Depending on how many rows you expect to be clustered per cluster key, 
and their average length, it may be to your advantage to specify a logical 
block size for the cluster. By choosing a good logical block size space is 
better utilized and fewer read operations will be required during physical 
scans. Indicate a logical block size in bytes, allowing some room for up¬ 
dates or insertions for each cluster key. The logical block size should be 
less than the ORACLE block size, which is operating system dependent. 

You should request your best estimate of logical block size. The size you 
request will be adjusted by ORACLE (usually a bit larger, to an integral 
division of the physical block). The algorithm used and number of logical 
blocks per ORACLE blocks varies according to the cluster key size and 
by operating system, but generally one logical ORACLE block can equal 
up to six or seven logical cluster blocks. Generally, logical blocks can be 
no smaller than 300 bytes. To sec the requested and actual sizes, use the 
following query: 

SELECT REQBLK, LOGBLK 
FROM CATALOG 

WHERE TNAME = <tablename> 

Choose the logical block size carefully. Try to use smaller logical block 
sizes if possible, but avoid creating many chained blocks. If few records 
are clustered on the same key, smaller logical block sizes are preferable to 
avoid wasting storage space. You should try to choose a size between the 
average and the maximum logical block size that strikes a balance between 
wasted space in the blocks and the need to create chained blocks. 


Clusters and Space Definitions 

The size of a cluster is determined by the space definition used when the 
cluster is created. Note that the parameter PCTFREE docs not apply for 
clusters. That space definition controls the space available for all tables in 
that cluster. 


Hints on Using Clusters 

Choose cluster key columns carefully. If more than one column is com¬ 
mon to the clustered tables, make the cluster key a concatenated key. Too 
little data stored for each key (few rows per cluster key) may waste space 
and earn negligible performance gains. l oo much data per key may cause 
excessive chaining, reducing performance. 

Use clustering when two or more tables are often joined. If clusters arc 
later deemed not useful, the tables can be unclustercd. 
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Occasionally the data of a single table will warrant clustering that table 
only; this is true when one or more columns have several values in com¬ 
mon which are frequently used for queries. 

Bulk loading a table into a cluster from an existing table can place a heavy 
demand on the before image file, especially if the cluster already contains 
one or more tables. 


Loading Clusters 


After a cluster is created, you can specify which tables it will contain. At 
least one column in the table, corresponding to one of the cluster key col¬ 
umns, must be defined as NOT NULL in the CREATE TABLE state¬ 
ment. Tables are added to the cluster using the CREATE TABLE 
statement; variations of this statement allow you to cluster new or old ta¬ 
bles: 

To cluster a new table: 

CREATE TABLE new_table 

(coll datatype, col2 datatype, ..., coin datatype) 
CLUSTER cluster_name (table_column) 

To copy an existing table into a cluster, first use one statement to create, 
cluster, and load a new table: 

CREATE TABLE <new_table_name> 

CLUSTER <cluster_name> (<table_column>) 

AS SELECT * FROM <existing_table> 

Then drop the old table which was not clustered: 

DROP TABLE <ex1sting_table> 

Then rename the table you created in a cluster to the previous table's name 
if you so wish: 

RENAME <new_table_name> TO <existing_table_name> 

Tables may be clustered with or without data. I/ess overhead is entailed if 
empty tables are added, because it only requires some updates in the data 
dictionary and changing the initial blocks assigned to the table. More 
overhead (performance or execution time) is required to copy tables with 
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data, because all the existing data must be read and moved from the table's 
blocks to the the cluster's blocks. 


Dropping Clusters 


Before a cluster can be dropped, each table in the cluster must be dropped 
from the cluster. 


ORACLE CONTEXT SPACE 


The context space is the buffer used to contain the SQL statement in exe¬ 
cution, and if the statement is a query, then one row of the result and the 
headings for the result. 

In ORACLE V5, context space is dynamic, which means that ORACLE 
extends context space when needed, rather than raising an error and forcing 
the user to do it. This generally removes the need for users to worry about 
context space. If a user exhausts the space in his context area, new area is 
allocated if at all possible. The following paragraphs give more detail on 
how space is allocated. 

When a context area is created (during OOPEN), an initial area, called the 
primary extent, is allocated. If a size is given in the OOPEN call, this size 
is used; if not, then the parameter specified in INIT.ORA at the last warm 
start is used (CONTEXT_SIZE); if that parameter was not specified, then 
the system constant context size is used (in most systems this is 4K). 

When space is needed in a context area and there is not enough room in 
the already-allocated area, a new area is allocated to be used along with the 
existing area. This area is called a secondary extent. The target size for this 
area is the size specified in CONTEXT INCR in INIT.ORA, or the sys¬ 
tem constant context increment (usually 4K) if this parameter is not spec¬ 
ified. However, if this size won't yield an area large enough for the current 
space requirement, then an area large enough for this requirement is allo¬ 
cated. The secondary extent size cannot be specified in the OOPEN call. 

This process continues as storage is required, until either the operating 
system refuses to provide any more storage, perhaps because virtual mem¬ 
ory is full, or until the maximum number of context extents is reached. 
This is a system constant which is not settable in INIT.ORA, and is cur¬ 
rently 50. With normal parameters and usage, only a very large context 
area would actually cause exhaustion. 
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Once storage has been allocated to a context area, it is available for subse¬ 
quent statements parsed in that context area. It is not freed until the cursor 
is closed. The context area may be reset to its initial size by closing and 
reopening, it. 


OPERATOR PRECEDENCE 


The use of parentheses to clarify the meaning of more complex SQL 
statements is recommended. For example, without parentheses the mean¬ 
ing of the following SQL statement is not obvious: 

SELECT ENAME, DEPTNO 
FROM EMP 

WHERE JOB = 'CLERK' 

AND DEPTNO = 10 
OR DEPTNO = 20 

because a user could interpret it as either of the two requests: 

1. Display names and departments of all clerks in department 10 and any¬ 
one in department 20 

2. Display names and departments of all clerks but only if they are in de¬ 
partment 10 or department 20 

Assume we want to see the names and department numbers of all clerks 
who work in either department 20 or department 30. If we add punctu¬ 
ation we can change the meaning of the query (and thus its output) as well 
as clarify our intention. If we use no punctuation: 

SELECT ENAME, DEPTNO 
FROM EMP 

WHERE JOB = 'CLERK' 

AND DEPTNO = 20 
OR DEPTNO = 30 

the result is all clerks who work in Dept 20, and all employees in Dept 30: 
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ENAME 


DEPTNO 


ALLEN 

WARD 

MARTIN 

TURNER 

ADAMS 

JAMES 


30 

30 

30 

30 

20 

30 


If we add parentheses around (DEPTNO = 20 or DEPTNO = 30): 

SELECT ENAME, DEPTNO 
FROM EMP 

WHERE JOB = 'CLERK' 

AND (DEPTNO = 20 
OR DEPTNO = 30) 

the result is all clerks who work in Dept 20 or Dept 30 (the desired result): 

ENAME DEPTNO 


ADAMS 20 

JAMES 30 

If we add parentheses in a different place: (JOB = 'CLERK' OR 
DEPTNO = 20): 

SELECT ENAME, DEPTNO 
FROM EMP 

WHERE (JOB = 'CLERK 1 
AND DEPTNO = 20) 

OR DEPTNO = 30 


the result is the same as the result with no punctuation, but it is not as 
ambiguous — all clerks who work in Dept 20 and all employees in Dept 


30: 
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ENAME 

DEPTNO 

ALLEN 

30 

WARD 

30 

MARTIN 

30 

TURNER 

30 

ADAMS 

20 

JAMES 

30 


OPTIMIZING VARIOUS SQL STATEMENTS 


Optimizations Automatically Performed 


This section briefly describes how some ORACLE optimizations work, 
over which the user has little or no control. Sections following this one 
describe various situations where the user may be able to have an impact 
by re-wording certain SQL statements. 


Using DISTINCT 

Given a SQL statement with one or more DISTINCT SELECT list items 
requested, ORACLE discards duplicates during sorting, as they are en¬ 
countered. 

Indexes are not generally used to process DISTINCT queries. 

Using GROUP BY 

GROUP BY queries are processed similarly to DISTINCT queries; given 
a GROUP BY query, ORACLE aggregates groups during the sort and 
discards duplicates as they are encountered. 

Indexes are not used for GROUP BYs. 

Subquerics 

Certain subqueries are automatically transformed into joins. Queries using 
IN can sometimes be transformed into joins. For example: 

SELECT * FROM EMP 
WHERE EMP.DEPTNO IN 

(SELECT DEPTNO FROM EMP) 
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can be processed as the following logical query, which is not in valid SQL, 
syntax: 

SELECT EMP.A FROM EMP, D: 

(SELECT DISTINCT DEPTNO FROM DEPT) 

WHERE D.DEPTNO = EMP.DEPTNO 

Other similar transformations are performed automatically as well. 


Single Row Query Paths 

When a query path can be guaranteed of pointing to a single row, that 
query path is processed first in a join. Examples of such paths include: 

• Unique index paths 

• single set views (such as SELECT AVG(SAL) PROM EMP) 

• ROWID paths 

Optimizing Queries (SELECTS) 


On a single, small table, ORACLE will perform reasonably fast sequential 
scans; indexes are unnecessary. However, when retrieving data from mul¬ 
tiple tables (joins) or searching large tables (many rows), then the use of 
indexes or clusters can considerably reduce the query time. Specifically, if 
columns named in the WHERE clause are indexed or clustered, the search 
will be much faster than if they are not. 

When many columns are named in the WHERE clause (indexed, clustered, 
or neither), ORACLE follows a set of rules to determine which WHERE 
conditions to test first (that is, which column criteria will "drive" the query). 
For example, evaluating one WHERE clause first may eliminate imme¬ 
diately 75% of the rows from a large table, where evaluating the other 
clause first might eliminate only 15% from a different large table. In all 
cases, ORACLE chooses, based on these rules, a starting point from which 
to proceed with all the testing against WHERE clauses; this starting point 
we call the "driving" column or condition. 

Note that the rules underlying the query optimizer may change over time 
and between ORACL,E versions. As Oracle Corporation continues its re¬ 
search and development of optimization, it is possible that different opti¬ 
mization paths might be chosen for the same query in different versions 
of ORACLE. General rules of thumb which can be drawn from these 
rankings are: 
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These: 


are faster than 


These: 


indexed columns 
unique indexes 
ROWID (= constant) 
bounded range 
pattern match like 'x%' 
in some cases: 
noncompressed indexes 


unindexed columns 
nonunique Indexes 
any other search 
unbounded range 
pattern match like '%x%' 

compressed indexes 


Optimizing NOTS 


ORACLE does not use indexes for predicates containing not equal clauses 
(as in != or NOT =), though it may use an index on another predicate. 
For example, in 

WHERE X != 7 AND Y = 8 

though no index is used for column X, an index could be used for Y. 
Usually in queries with "NOT = " the number of rows returned is greater 
than the number of rows skipped. For ORACLE to read the index and 
then the table requires an extra I/O. Thus it's usually faster to do a full 
table scan than use an index. 

When the predicate contains NOT in conjunction with other operators, 
however, ORACLE transforms the predicate into one with which indexes 
can be used, as follows: 


NOT > 

transforms to 

<= 

NOT >= 

transforms to 

< 

NOT < 

transforms to 

>= 

NOT <= 

transforms to 

> 
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Optimizing ORS 


SQL statements using OR clauses use indexes under some circumstances. 
The optimization also applies to IN clauses which translate to ORs — 

This: means the same as this: 

DEPTNO IN (X, Y, Z) DEPTNO = X OR DEPTNO = Y 

OR DEPTNO = Z 

Generally, optimization will occur if the columns in the OR predicates are 
indexed, but optimization may not occur if some columns are indexed but 
some are not. 

Given a query such as: 

SELECT * 

FROM EMP 

WHERE DEPTNOT = 10 or JOB = 'CLERK' 

and indexes exist on both the columns DEPTNO and JOB, ORACLE will 
use both indexes and perform something like (but not exactly equivalent 
to) the union of the two queries: 

[Query 1] [Query 2] 

SELECT * SELECT * 

FROM EMP FROM EMP 

WHERE DEPTNO = 10 WHERE JOB = 'CLERK' 

AND DEPTNO != 10 

Knowing this, it is best to put the most specific index first in the predicate 
list, and the predicate that passes the most records last. T his will minimize 
the number of checks for "not equal to". 

OR predicates arc not used for optimization in the following cases: 

• when the SQL statement contains a CONNECT BY 

• when the SQL statement contains an outer-join 

• whep it decides that use of indexes will not optimize the query. 
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The ORACLE Sort/Merge Routine 


The Version 5 Sort/Merge routine of ORACLE RDBMS improves per¬ 
formance on several operations, such as CREATE INDEX, SELECT 
DISTINCT, ORDER BY, GROUP BY, and certain joins. Simply de¬ 
scribed, incoming data which must be ordered is first internally sorted into 
several sets of ordered runs, and then these runs arc merged into a final, 
sorted result. One advantage of the sort/merge routine is that it can avoid 
the creation of temporary tables and thus disk activity, if enough internal 
work area is available to accomplish the sort/merge. 

Several INIT.ORA parameters relate to the sort/merge routine; see 
“INIT.ORA Parameter Detailed Descriptions” on page 27 for descriptions 
of the following parameters: 

• SORTAREASZ 

• SORTFINALRA 

• SORTMERGERA 

• SORTPOOLSZ 

• SORTSPCMAPSZ 

• SORT READ_FAC 

There are two work areas related to the sort/merge routine: 

internal This size is set by the INIT.ORA parameter SORT AREA SZ, 
and increases in the parameter will increase the SGA size and may 
improve performance. 

external This area is used for storage of runs before and during the merge. 

External work area is allocated via temporary tables, and managed 
just like temporary tables. In the worst case, an external work 
area (temporary table) of twice the size of the column(s) being 
sorted may be required, in order to accomplish the final merge 
pass. 


Optimizing ORDER BY 


Thqugh there may be several ways to word a SQL statement to achieve the 
ordering you desire, the only way to guarantee ordering is to use the OR¬ 
DER BY clause at the end of your SQL statement. Results which appear 
ordered, but were not obtained using an ORDER BY clause, may not be 
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returned in the same order in future releases. Thus, it is preferred to ex¬ 
plicitly request ordering via the ORDER BY clause. 

For a query with an ORDER BY clause, first the data which meets the 
selection criteria is extracted, and then it is sorted using sort/merge. 


Optimizing GROUP BY 


It is preferable to eliminate rows not meeting selection criteria as early as 

possible (in the WHERE clause) so the rows do not incur extra processing. 

For example, the following query 

SELECT JOB, AVG(SAL) 

FROM EMP 

WHERE JOB != 'PRESIDENT' AND JOB != 'MANAGER' 

GROUP BY JOB 

is better than the query: 

SELECT JOB, AVG(SAL) 

FROM EMP 

GROUP BY JOB 

HAVING JOB != 'PRESIDENT' AND JOB != 'MANAGER' 

for two important reasons: 

1. Because there's no WHERE clause, all rows, including those which 
might have been eliminated with a WHERE clause, incur processing - 
but some rows could have been "discarded" earlier. 

2. HAVING clauses are intended to eliminate grouped data based on group 
criteria (such as less than a minimum or greater than average). Though 
their syntax is similar to that of WHERE clauses, HAVING clauses 
cannot always (and therefore should not) be used interchangably with 
WHERE clauses. 


Optimizing Joins 


Some general rules for optimizing join performance arc: 
• columns used in join clauses should be indexed 


178 / The ORACLE Database Administrator's Guide 






• SQL statements should be worded so as to use indexes, rather than 
suppress their use (that is, watch the wording of the predicates so that 
the use of indexes is not inadvertently suppressed). 


Unindexed Joins 


If no indexes exist on the joined columns in a join, a "sort-merge" join is 
performed, as long as the following are true: 

• there is no other query path usable by ORACLE (If ORACLE deter¬ 
mines that indexes can be used to execute the query, it will use indexes 
and not the sort/merge.) 

• the join clause must be of the form tab a.expression = tabb.expression, 
as in: 

tab_a.col_a + 1 = to_number (tab_b.col_b) 

For example, the join may not be a greater-than-or-equal. Outer-joins, 
however, may be performed by sort/merge. 

In a sort-merge join, each table to be joined is processed separately; records 
that pass a table are sorted. Then the sorted lists are merged, based on the 
column forming the join. 


Indexed Joins 


If only one of the tables being joined has a useable index, the other table 
is usually the driving table. For example, if EMP.DEPTNO is indexed and 
DEPT.DEPTNO is not indexed, then in both the following queries, the 
DEPT table is the driving table: 

SELECT ENAME, DNAME SELECT ENAME, DNAME 

FROM DEPT, EMP FROM EMP, DEPTNO 

WHERE EMP.DEPTNO = DEPT.DEPTNO WHERE EMP.DEPTNO = DEPT.DEPTNO 

AND JOB != 1 SALESMAN 1 AND JOB != 'SALESMAN' 

Exceptions include when a query path is guaranteed to be a single row 
query path; see “Optimizations Automatically Performed” on page 173. 
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If indexes exist on both the joined columns or on subsequent selection 
predicates, then ORACLE ranks the access paths based on their selectivity, 
in order to choose the optimal path. In general, ORACLE considers: 

• which predicates can use indexes 

• which indexes are unique 

• whether indexes are on NOT NULL columns 

In constructing the query, you should also consider: 

• the number of records in the tables queried 

• the distribution of data indexed by a nonunique index, 
which may also impact performance. 

The actual query path ORACLE chooses is a result of weighing all paths 
against each other with a ranking scheme. The rankings (lowest number 
is fastest path) determine which table will be the driving table. Every 
AND'ed WHERE clause is evaluated separately and is scored in the fol¬ 
lowing sequence, from lowest (fastest) to highest (slowest). Concatenated 
index means either an index composed of multiple columns in a table or a 
cluster key. 

Each WHERE clause joined by an AND is ranked, and so is each join or 
outer-join. 

Eigure 36 on page 181 shows the ranks for the different query paths. 

Joins are scored on the number of tables which will be joined without an 
index and the number of cartesian products. 

If ranks arc equal, then, as when there are no indexes, ORACLE uses the 
last table in the PROM clause as the driving table. Thus, you should list 
large tables with the smallest number of qualified rows last in the FROM 
clause, and when writing a multi-table join (3 or more tables), list the join 
clause for the pair of tables resulting in the smallest result set last, in the 
list of join clauses. 

If a certain table has a low score for a search, but can only be joined to 
other tables without the use of indexes, then another table that can join 
with indexes will be chosen as the driver. The join score always dominates 
the cumulative score. 
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RANK 

PATH 

NOTE: 

Lowest ranks are fastest paths. 

1 

ROWID = constant 

2 

unique indexed column = constant 

3 

entire unique concatenated index = constant 

4 

entire cluster key = corresponding cluster key in another 
table in same cluster 

5 

entire cluster key = constant 

6 

entire nonunique concatenated index = constant 

7 

nonunique index = constant 

8 

entire noncompressed concatenated index > = lower bound 

9 

entire compressed concatenated index > = lower bound 

10 

most leading noncompressed concatenated index specified 

11 

most leading compressed concatenated index specified 

12 

unique indexed column BETWEEN low value AND high value, or 
unique indexed column LIKE 'C%' (bounded range) 

13 

nonunique indexed column BETWEEN low value and high value, or 
nonunique indexed column LIKE 'C%' (bounded range) 

14 

unique indexed column < or > constant (unbounded range) 

15 

nonunique indexed column < or > constant (unbounded range) 

16 

sort/merge (joins only) 

17 

MAX or MIN of single indexed column 

18 

ORDER BY entire index 

19 

full table scans 

Figure 36. Query Path Speed Rankings 


ARRAY PROCESSING 


The new array processing feature of Version 5 ORACLE RDBMS allows 
multiple rows to be processed at once. Array processing can yield as much 
as ten times the performance as single row operations. Typical array sizes 
of 100 or more rows at a time are most optimal. The ORACLE utilities 
ODL and Export/Import all can use arrays to speed execution time. Users 
can sec performance gains in INSERTS and SELECTS when using arrays 
in the Pro + products (Pro+FORTRAN, Pro+COBOL, Pro*C, Pro*PL/I, 
Pro*PASCAL, etc.). For a description of datatypes and call syntax, see the 
guide pertaining to the programming language of interest, as in the 
Pro* FORT RAN Users Guide . 
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PART V: ORACLE RDBMS SECURITY 
MANAGEMENT 


This part discusses ORACLE features which allow the DBA to control 
access to the database and to track changes or attempted changes to the 
data. The AUDITing facility is also described, which allows users and 
DBAs to track database use at several different levels. 
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CHAPTER 11. ENROLLING AND DROPPING USERS 


This chapter describes the SQL commands used to give users database 
privileges and take them away. Login options arc discussed. 

This chapter addresses one of the most frequent duties of the DBA: en¬ 
rolling and dropping users from an ORACLE RDBMS system. 

Every ORACLE user must have access (an id and password) to the oper¬ 
ating system; however, the operating system id and password arc totally 
independent of ORACLE (and may even be granted after access to 
ORACLE is granted). 

The ORACLE DBA grants users access to ORACLE with an ORACLE 
username and password, just as with the operating system. 


ENROLLING USERS 


There are three classes of ORACLE users, corresponding to the privileges 
they have been granted. Listed in order of increasing privileges, they are: 

• CONNECT 

• RESOURCE 

• DBA 

When a new user is enrolled in the ORACLE database, the DBA grants 
the user one or more of the privileges, using the SQL statement GRANT: 

GRANT { CONNECT | RESOURCE | DBA j TO <username> 

[ IDENTIFIED BY <password> ] 


as in: 
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GRANT CONNECT, RESOURCE TO FRIEDA IDENTIFIED BY SANTAFE; 


In the first example, the name and password used for ORACLE (FRIEDA 
and SANTAFE, respectively) need have no relationship to the operating 
system; for example, FRIEDA'S operating system id might by 
FLAWRENCE and password COAL. There is one exception, noted in 
“Automatic Logins” on page 188, where the DBA can use related id's in 
order to simplify the logon process. 

The IDENTIFIED BY clause is required if the CONNECT’ privilege is 
being granted. If a user already exists, you can grant additional privileges 
without the IDENTIFIED BY clause, as in: 

GRANT DBA TO KNOWITALL; 

which assumes that KNOWIT ALL was an existing ORACLE user who 
did not previously have DBA privileges. 


Users with CONNECT Privilege 


You must have CONNECT privilege in order to access any of the 
ORACLE utilities or the database. Every user with CONNECT’ is identi¬ 
fied by both a username and a password. The username and password are 
stored in the data dictionary. Each time the user logs on the name and 
password are checked against the dictionary for validity. 

It is possible for a user to have only the CONNECT privilege. Such a user 
may: 

• access ORACLE 

• look at other users' data (SELECT from tables and views), if SELECT 
access has been granted 

• perform data manipulation operations (INSERT’, UPDAT E, DELETE) 
on other users' tables, if the corresponding access has been granted 

• create views and synonyms. 

However, he may not create any tables, clusters, or indexes. 


186 / The ORACLE Database Administrator's Guide 















Users with RESOURCE Privilege 


If you have both RESOURCE and CONNECT privileges, you have all the 
privileges associated with the CONNECT privilege. In addition, you may: 

• CREATE database tables, indexes, and clusters 

• GRANT privileges on those objects to other users and REVOKE those 
privileges 

• use the AUDIT command to control auditing of access to objects you 
own. 


Users with DBA Privilege 


If you have DBA privilege, you have all the privileges granted by CON¬ 
NECT and RESOURCE, and in addition you may: 

• access any user's data, and perform any SQL statement upon it 

• GRANT and REVOKE users database access privileges (different from 
access privileges to database objects) 

• create PUBLIC synonyms (which are available to all ORACLE users) 

• create and alter partitions 

• control system-wide auditing and table-level auditing defaults 

• perform full database exports. 

Though in this document we commonly refer to "the DBA", in reality an 
ORACLE system may have numerous DBAs, because a DBA is any user 
with DBA privilege. However, because the DBA has such freedom, 
normally you will want to limit the number of users with DBA privilege. 

Every ORACLE system is installed with two DBA users: SYS and SYS¬ 
TEM. Because these two users arc essential to ORACLE'S operation, their 
access to the ORACLE system should not be altered, other than changing 
their initial passwords. DBA duties can be performed by a user logging on 
to the SYSTEM id or by creating a third ORACLE id, with DBA privilege, 
specifically to perform DBA duties. See Section “SYS and SYSTEM: The 
ORACLE DBA Users” on page 14 for more information on the users SYS 
and SYSTEM. 
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AUTOMATIC LOGINS 


When enrolling ORACLE users, the DBA may optionally tie users' 
ORACLE ids to their system ids. The benefit is that users enrolled in this 
way need not type their ORACLE username or password to log in to 
ORACLE. The syntax for granting automatic logins is shown in 
Figure 37. 


GRANT CONNECT TO OPS$<opsys_id> IDENTIFIED BY password; 


Figure 37. Granting Autologin Users 

For example, to enroll a user whose system id is OPUS, a DBA might 
enter: 

SQL> GRANT CONNECT, RESOURCE TO 0PS$0PUS IDENTIFIED BY PENGUINS; 

The grant syntax is the same except for the prefix "OPS$" on the ORACLE 
user name which signifies to ORACLE an automatic login username. I he 
password (PENGUINS, in this example) can be any arbitrary string, and 
as for other users, can be subsequently changed. Oracle Corporation re¬ 
commends using unique passwords for automatic login accounts. 

Subsequently, when a user logged onto the operating system as OPUS logs 
in to ORACLE, he need not enter the username and password. Tor ex¬ 
ample, after entering the command SQLPLUS and pressing return, 
ORACLE will search in the dictionary tables for an automatic login cor¬ 
responding to the operating system account name OPUS, and finding it, 
allow OPUS to log in to ORACLE as OPSSOPUS. 

Users can log in to ORACLE by specifying a full username and password 
when desired. For example, a user logged on to the operating system as 
BILL can issue the following: 

SQL> CONNECT OPS$OPUS/PENGUINS 

Thus, even though the current system name is BILL, ORACLE validates 
the login for OPSSOPUS as long as the proper password is supplied. 
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Therefore, rt is important for security that each OPS$ username have a 
confidential password. 

Because the ORACLE username is the whole name "OPS$OPUS", all 
objects created by OPSSOPUS (tables, views, indexes, etc.) are prefixed 
by this name. For example, for another user to reference a table, FISH, 
owned by OPSSOPUS, he would have to enter: 

SELECT * FROM 0PS$0PUS.FISH; 


CHANGING PASSWORDS 


The password for any existing ORACLE user can be changed by that user 
or the DBA. Simply use the GRANT CONNECT command supplying 
the new password, as in 

SQL> GRANT CONNECT TO olduser IDENTIFIED BY newpassword; 


DROPPING USERS 


To take database privileges away from a user, use the SQL statement RE¬ 
VOKE: 

REVOKE { CONNECT | RESOURCE | DBA } FROM user 

as in: 

REVOKE CONNECT FROM EDISON; 

Only the DBA can change a user's privileges, and he may do so at any 
time, using the GRANT or REVOKE statements. User's privileges may 
be increased or decreased by selectively granting or revoking privileges. 

If the CONNECT privilege is taken away from a user, that user cannot 
connect to ORACLE unless he is given CONNEC T privilege again. 

Tables belonging to a dropped user continue to exist, although the user has 
been dropped from the data dictionary. The DBA can continue to access 
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these tables, as can other users given access to them. If the user is recre¬ 
ated, he 'regains" his tables. 


THE SPECIAL "USER" PUBLIC 


Every ORACLE system automatically enrolls a user called PUBLIC. This 
user is actually a group , to which every user with CONNECI access to 
ORACLE belongs. 

As members of PUBLIC, ORACLE users may see (SELECT from) all 
data dictionary tables, and any table for which the owner has run the fol¬ 
lowing SQL command: 

GRANT SELECT ON tablename TO PUBLIC; 

If you create tables (or views) of interest to many users, you can run this 
GRANT statement too. 


PUBLIC SYNONYMS 


Public synonyms are synonyms which a DBA has created and which are 
therefore available to all ORACLE users to access. Por example, by en¬ 
tering: 

CREATE PUBLIC SYNONYM synname ON { table | view | synonym } 

the DBA can create a synonym for a table, view, or another synonym 
which can be used by all users. Public synonyms are automatically created 
for the data dictionary views, as in: 

CREATE PUBLIC SYNONYM SYSTABAUTH FOR SYSTEM.SYSTABAUTH; 

so that users can simply select from SYS IABAUIII, rather than always 
needing to remember to type SYSTEM.SYS I ABAU TII. 

To see what public synonyms exist, enter: 

SELECT * FROM PUBLICSYN; 
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Only users with DBA privilege can create public synonyms. 

An ORACLE user can create an object with the same name as a public 
synonym. However, upon later referencing that name, the user will always 
see his object and never the object given the public synonym. In order to 
reference that object, he must use the fully qualified name. For example, 
if SCOTT creates a table named TAB, then the query 

SELECT * FROM TAB 

will return whatever is in the table or view SCOTT called TAB, rather than 
a list of SCOTT's own database objects. 


LOGIN.SQL FILES 


Each time an ORACLE user invokes SQL*Plus, SQL*Plus looks for a file 
called LOGIN.SQL and executes it if it is found. (Check the Installation 
and User's Guide for your operating system to see where to put system- 
wide or individual LOGIN.SQL files.) This file contains SQL statements 
or SQL*Plus commands which will be in effect at the beginning of the 
SQL*Plus session. This file can be used to set your own SQL*Plus session 
defaults to replace those set by SQL*Plus. 

The LOGIN.SQL file can contain any command valid in SQL*Plus. A 
sample file is shown in Figure 38. 


set echo off 
set feedback 10 
set pause on 

set pause "Enter return to continue" 

set message on 

set linesize 100 

select * from myreminder; 


Figure 38. 


Sample LOGIN.SQL File 
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CHAPTER 12. USING ORACLE AUDITING 


This chapter describes ways a DBA can improve and monitor the security 
of a database system. Topics include enabling and using the auditing fea¬ 
tures. 


AUDITING 


Auditing as described in the following sections is new in ORACLE Version 
5. ORACLE auditing is primarily a security feature. It does not record the 
values of columns updated, inserted, or deleted from the database. How¬ 
ever, it can be used to monitor user activity on an ORACLE database. 

By default, there is no auditing activity. However, if enabled, the auditing 
feature allows any ORACLE user who owns a table or view: 

• use SQL statements to choose auditing options 

• audit successful and/or unsucessful attempts to access his tables or views. 

• selectively audit different types of SQL operations (such as UPDATES 
only - INSERT, UPDATE, DELETE - or also SELECTs). 

• control the level of detail recorded in the audit trail (session vs. access) 

Eor example, the following statement would audit successful alterations to 
the EMP table (such as adding a new column): 

AUDIT ALTER ON EMP BY ACCESS WHENEVER SUCCESSFUL 

Auditing also lets the DBA: 

• monitor successful and/or unsuccessful attempts to log on and log off 
ORACLE and to GRANT or REVOKE privileges 

• enable or disable writing to the audit trail table (SYS.AUDIT’TRAIL) 
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• set the default auditing options (if any) for database tables. 

The SQL AUDIT statements are similar to the SQL GRANT and RE¬ 
VOKE statements. Descriptions of audited operations are written to a data 
dictionary table, SYS.AUDITTRAIL, also called the "audit trail". This 
table can then be used, like all other dictionary tables, for querying or re¬ 
porting on database activity. 

Enabling System Auditing 


By default auditing is disabled. It can be enabled easily at any start of the 
system (during an IOR 1NIT or IOR WARM). To enable auditing, set 
the parameter AUDIT JTRAIL in the INIT.ORA parameter file to a 
non-zero integer (the AUDI F TRAIL parameter is distributed as zero, 
which turns auditing off). 1 hen warm start the ORACLE system using the 
edited INIT.ORA file. 

After the system has been started, auditing is enabled. As no type of au¬ 
diting is automatic, users and the DBA then use the SQL AUDIT state¬ 
ments to indicate which actions should be audited. 

The DBA may choose to: 

• set some system defaults (such as auditing all successful attempts to 
ALTER any ORACLE table) 

• exercise DBA-only auditing options (such as auditing all unsuccessful 
attempts to access the database itself). 

Users owning tables, views, or synonyms can indicate which actions upon 
those objects they would like audited. 

Auditing Tables and Views 


Different levels of auditing may be specified for each database table. The 
AUDIT statement specifies which operations on a particular table should 
be audited. For any given database object (table, view, or synonym) the 
only users who can enter an AUDI T command arc the object's owner or 
the DBA. 
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AUDIT {<t_option> [, <t_option>]... | ALL } 
ON { <t_name> DEFAULT } 

[ BY { ACCESS SESSION } ] 

[ WHENEVER [ NOT ] SUCCESSFUL ] 


where <t_option> is: 


ALTER 

AUDIT 

COMMENT 

DELETE 

INSERT 

LOCK 

RENAME 

SELECT 


GRANT | INDEX 
UPDATE 


For example: 


AUDIT ALTER, SELECT, UPDATE ON SCOTT.EMP 
WHENEVER SUCCESSFUL 


The tname must be a the name of a view, base table, or a synonym de¬ 
noting a view or base table. 

The option list specifies one or more SQL statements referencing t_name 
that should be audited. The GRANT option indicates that both the 
GRANT and REVOKE statements on T should be audited. 

For base tables, all auditing options are applicable. For views, the appli¬ 
cable options are AUDIT, COMMENT, INSERT DELETE, GRANT, 
LOCK, RENAME, SELECT, and UPDATE. ALL is equivalent to a list 
of all options applicable on the t name. 

The BY clause determines which situations will cause rows to be written 
to the audit trail. Because some events happen much more frequently than 
others (DML commands occur much more often than GRANTS, 
normally), the BY clause also determines how often and how many rows 
are written to the audit trail. Choices arc: 

BY SESSION T he specified operations are audited by updating informa¬ 
tion in T's session record. T has at most one session record in 
the audit trail per user ORACLE session. A missing BY clause 
is equivalent to BY SESSION. 

BY ACCESS Each specified operation is audited by inserting one or more 
rows in the audit trail. For a DML operation all audit trail rows 
are written or updated at the completion of the operation's "parse 
phase". 

The WHENEVER clause further qualifies which audited operations should 
be written to the audit trail. 
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WHENEVER SUCCESSFUL Each specified operation should be audited 
only when it successfully completes. 

WHENEVER NOT SUCCESSFUL Each specified operation is audited 
only if it does not successfully complete. 

A missing WHENEVER clause is interpreted to mean auditing should be 
done on both successful and unsuccessful completion. Note that for a 
DML operation, the term 'completion' 7 means the completion of the op¬ 
eration's "parse phase" (parse, dictionary lookup, security check, or OSQL3 
call), which is not precisely the same as its "execution". 

When a table is created, its auditing options default to those specified on 
the DEFAULT table. Only the DBA can specify these options, by using 
the keyword DEFAULT rather than a tablename in the AUDIT state¬ 
ment. Before the first use of the AUDIT ... ON DEFAULT statement, 
the default table auditing options are that nothing is audited. 

When a view is created, its auditing options arc set to the union of the 
DEFAULT table auditing options and the auditing options of all base ta¬ 
bles referenced by the view. The "union" of BY ACCESS and BY SES¬ 
SION is BY ACCESS. 

The table NOAUDIT statement specifics which operations on a particular 
table should no longer be audited: 

NOAUDIT { <t_option> [, <t_option>]... | ALL } 

ON { <t_name> | DEFAULT } 

[ WHENEVER [NOT] SUCCESSFUL ] 

For example: 

NOAUDIT ALL ON emp 

The NOAUDIT statement's syntax is like that of the AUDIT statement. 
The main difference is that it has no BY clause; the specified auditing ac¬ 
tivity is terminated whether it is BY ACCESS or BY SESSION. Options 
specified in a NO AUDIT statement need not be audited currently. 


196 / The ORACLE Database Administrator's Guide 












SETTING SYSTEM AUDITING OPTIONS 


Different levels of auditing may also be specified for DBA operations and 
operations that do not apply to database tables. The AUDIT statement 
is also used to specify such system auditing options. 

AUDIT { <s_option> [, <s_option>]... I ALL } 

[ WHENEVER [NOT] SUCCESSFUL ] 

Where < soption > is: 

CONNECT | DBA | NOT EXISTS | RESOURCE 

For example: 

AUDIT CONNECT, DBA WHENEVER SUCCESSFUL 

The syntax and semantics of the system AUDIT’ statement resemble those 
of the table AUDIT statement. The main difference is in the operations 
which are audited. Each option identifies a class of database operations to 
be audited. The options are: 

CONNECT ORACLE logon and logoff 

DBA System-wide GRANT, REVOKE, AUDIT and NOAUDIT 

statements; CREATE/ALTER PARTITION; CREATE/DROP 
PUBLIC SYNONYM 

NOT' EXISTS All references to objects which result in the "... does not 

exist" errors. This does not include security violation errors even 
though such errors appear to the user as error 942 (table or view 
does not exist). 

RESOURCE CREATE/DROP TABLE, VIEW, SPACE, SYNONYM; 
CREATE/ALTER/DROP CLUSTER; 

Before the first use of the system AUDIT statement, no system operations 
are audited. 

I’he system NOAUDIT statement specifics which system operations 
should no longer be audited. 

NOAUDIT [ <s_option> [, <s_option>]... I ALL j 
[ WHENEVER [NOT] SUCCESSFUL ] 


Chapter 12. Using ORACLE Auditing / 197 


















For example: 

NOAUDIT all WHENEVER NOT SUCCESSFUL 

The semantics of the NOAUDIT statement are analogous to those of the 
AUDIT statement. 


Auditing and the Data Dictionary 

The Data Dictionary contains several tables relating to auditing: 

SELECT * FROM DTAB WHERE TNAME LIKE '%AUDIT%'; 

TNAME REMARKS 


AUDIT_ACCESS 

AUDIT_ACTIONS 

AUDIT_CONNECT 

AUDIT_DBA 

AUDIT_EXISTS 

AUDIT_TRAIL 

DEFAULT_AUDIT 

SYSAUDIT_TRAIL 

SYSTEM_AUDIT 

TABLE AUDIT 


Audit entries for accesses to user's tables/views (DBA sees all) 
Maps auditing action numbers to action names 
Audit trail entries for user logon/logoff (DBA sees all users) 

Audit trail entries for DBA activities — for DBA use only 

Audit trail entries for objects which do NOT EXIST — DBA's only 

Audit trail entries relevant to the user (DBA sees all) 

Default table auditing options 

Synonym for sys.audit_trai1 - for DBA use only 

System auditing options -- for DBA use only 

Auditing options of user's tables and views (DBA sees all) 


Wliicli Actions arc Audited? 

The dictionary table AUDIT ACTTONS lists all possible actions which 
can be audited along with their numeric codes. Rather than the action 
name, the code is used in the other tables which record auditing informa¬ 
tion. 

A portion of the AUDIT_ACTIONS table follows: 
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SQL> SELECT * FROM AUDIT_ACTIONS WHERE ROWNUM < 10; 
ACTION NAME 


0 UNKNOWN 

1 CREATE TABLE 

2 INSERT 

3 SELECT 

4 CREATE CLUSTER 

5 ALTER CLUSTER 

6 UPDATE 

7 DELETE 

8 DROP CLUSTER 


The AUDIT TRAIL Tabic 


To see what entries have resulted from your auditing settings, you can se¬ 
lect from the dictionary table AUDIT TRAIL. Its columns are: 

SQL> describe audit_trail 


Name 


Null? Type 


USERID 

USERHOST 

TERMINAL 

TIMESTAMP 


NOT NULL DATE 


CHAR(30) 

CHAR(240) 

CHAR(240) 


0BJ$CREAT0R 

OBJ$NAME 


CHAR(30) 
CHAR(30) 


ACTION 


NOT NULL NUMBER 
NOT NULL CHAR(27) 


ACTION_NAME 

NEW$NAME 


CHAR(30) 

CHAR(6) 

CHAR(30) 

CHAR(ll) 

DATE 


AUTH$PRIVILEGES 


AUTH$GRANTEE 
SES$ACTI0NS 
L0G0FF$TIME 
LOGOFF$LREAD 
LOGOFF$PREAD 
L0G0FF$LWRITE 
LOGOFF$DEAD 
COMMENT$TEXT 


NUMBER 

NUMBER 

NUMBER 

NUMBER 

CHAR(240) 
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SESSIONID 
ENTRYID 
STATEMENT 
RETURNCODE 


NOT NULL NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 


Column SES$ACTTONS is an array of characters indexed by action type. 
The 11 entries of the array correspond to audit entries for the following 
activities: 

• alter 

• audit 

• comment 

• delete 

• grant 

• index 

• insert 

• lock 

• rename 

• select 

• update 

The action is encoded as: 

no session-auditable activity 

S action successfully executed 

F action unsuccessfully executed 

B action both successfully and unsuccessfully executed 

The [NOJAUDIT CONNECT' option enables and disables the logging of 
this information. 
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Listing Current Auditing Options 

To see what your current table auditing settings arc, refer to the dictionary 
table TABLE AUDIT. TABLE_AUDIT's columns are: 


SQL> describe table_audit 


Name 

Null? Type 

CREATOR 

CHAR(30) 

TNAME 

NOT NULL CHAR(30) 

TABLETYPE 

NOT NULL CHAR(7) 

ALT 

CHAR(3) 

AUD 

CHAR(3) 

COM 

CHAR(3) 

DEL 

CHAR(3) 

GRA 

CHAR(3) 

IND 

CHAR(3) 

INS 

CHAR(3) 

LOC 

CHAR(3) 

REN 

CHAR(3) 

SEL 

CHAR(3) 

UPD 

CHAR(3) 


Thus, to sec the options you have chosen for your own tables, you can use 
a query like the following: 


SQL> select * 

2 from table_audit 

3 where creator = 'SCOTT 1 ; 


CREATOR TNAME TABLETY ALT AUD COM DEL GRA IND INS LOC REN SEL UPD. 


SCOTT 

DEPT 

SCOTT 

EMP 

SCOTT 

INITORA 

SCOTT 

ORAFILES 


TABLE -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- 
TABLE -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- 
TABLE S/S -/- S/S S/S S/S -/- S/S A/- -/- S/S S/S 
TABLE A/S -/- -/- -/S -/- -/- A/S A/- -/- A/S A/S 


The columns on the right correspond to the list of actions which may be 
audited and the action to take if auditing has been enabled. Each column 
contains two characters per auditing option. The first character describes 
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what to do when the audited action succeeds and the second character de¬ 
scribes what to do when the audited action fails. The character codes are: 

do nothing 

A one audit record per access 

S one audit record per session 

Listing ORACLE System Auditing Settings 

A DBA can see which system auditing options are in effect by using the 
dictionary view SYSTEMAUDIT, described below: 

SQL> describe system_audit 
Name Null? Type 

C0NNECT$ 

DBA$ 

NOT_EXISTS$ 

RES0URCE$ 

A typical result might be: 

SQL> select * from system_audit; 

CON DBA NOT RES 
S/S S/- S/S -/- 

The Function USERENV 


CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 


The USERENV function allows you to obtain information about a par¬ 
ticular ORACLE session. It is used to insert records into the audit trail. 
USERENV takes a literal string as a parameter, and returns a string or 
number as its value, depending on its parameter: 
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SELECT USERENV('TERMINAL'), USERENV('SESSIONID'), USERENVf'ENTRYID') 
FROM DUMMY 
WHERE ROWNUM < 2; 


USERE USERENV('SESSIONID') USERENV('ENTRYID') 


RTA1: 14 2 

CONS 333 12 


(typical VMS entry) 
(typical VM entry) 


where: 


TERMINAL operating system terminal identifier. Returned regardless of 
whether or not auditing is enabled via the IN1T.ORA. The actual 
specification of the terminal id will vary according to the format 
for your operating system. 

SESSIONID user auditing session identifier. Only returned if auditing is 
enabled via INIT.ORA. 


ENIRYID next available audit_trail table entry number for the current 
session. Only returned if auditing is enabled via INIT.ORA. 

LANGUAGE Not illustrated in the example, this parameter reflects the 
setting provided for the parameter LANGUAGE used in the 
INIT.ORA file which was read when the database was started. 
By default this will be null, but it may be any character string up 
to 15 characters (see “LANGUAGE” on page 32). 

The USERENV function can be used to add a comment row to the audit 
trail as follows: 


INSERT INTO SYS.AUDIT_TRAIL ( SESSIONID, ENTRYID, STATEMENT, TIMESTAMP, 

USERID, TERMINAL, ACTION, RETURNCODE, 
COMMENT$TEXT ) 

VALUES ( USERENV ( 'SESSIONID' ), USERENV ( 'ENTRYID 1 ), 

0, SYSDATE, USER, USERENV ( 'TERMINAL' ), 0, 0, 

' Comment — transaction 73 beginning '); 


I he function USERENV can also be useful for constructing views which 
constrain access to users logged into certain physical terminals. For ex- 
ample: 
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CREATE VIEW MYVIEW AS 

SELECT * FROM MYSALARY 

WHERE USERENV( f TERMINAL') = 1 RTAO'; 

T he actual specification of the terminal id will vary according to the format 
for your operating system. Once you create the view, you must also grant 
access to it to selected ORACLE users: 

GRANT SELECT ON MYVIEW TO EVELYN; 

After both these statements, EVELYN will only see the rows in MYVIEW 
when she is logged on to terminal RTAO. Though she can access 
MYVIEW from other terminals, she will not see any rows through it. 
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APPENDIX A. RESERVED WORDS 


Reserved words are keywords which ORACLE uses and which users can¬ 
not use for names of objects, such as tables, columns, or views. If you 
inadvertently use a reserved word, the usual error message is that word is 
"not a valid name". Reserved words can only be used as names if they are 
enclosed in double quotes, as in "DEFAULT". 

ACCESS starting with ORACLE RDBMS V5 

ADD 

ALL 

ALTER 

AND 

ANY 

AS 

ASC 

ASSERT 

ASSIGN 

AT 

AUDIT starting with ORACLE RDBMS V5 

BETWEEN 

BY 

CHAR 

CLUSTER 

COLUMN 

COMMENT starting with ORACLE RDBMS V5 

COMPRESS 

CONNECT 

CONTAIN 

CONTAINS 

CREATE 

CURRENT 
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DATABASE 

DATAPAGES 

DATE 

DBA 

DECIMAL 

DEFAULT starting with ORACLE RDBMS V5 

DEFINITION 

DELETE 

DESC 

DISTINCT 

DOES 

DROP 

EACH 

ELSE 

ENDIF 

EVALUATE 

EXCLUSIVE 

EXISTS starting with ORACLE RDBMS V5 

FILE 

FLOAT 

FOR 

FROM 

GRANT 

GRAPHIC 

GROUP 

HAVING 

IDENTIFIED 

IF 

IFDEF 

IMAGE 

IMMEDIATE 

IN 

INCREMENT 

INDEX 

INDEXED 

INDEXPAGES 

INITIAL 

INSERT 

INTEGER 

INTERSECT 

INTO 

IS 
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LEVEL 

LIKE 

LIST 

LOCK 

LONG 

MAXEXTENTS 

MINUS 

MODE 

MODIFY 

MOVE 

NEW 

NOAUDIT 

NOCOMPRESS 

NOSYSSORT 

NOT 

NOWAIT 

NULL 

NUMBER 

OF 

OFFLINE 

OLD 

ON 

ONLINE 

OPTIMIZE 

OPTION 

OR 

ORACLE 

ORDER 

PARTITION 

PCTFREE 

PRIOR 

PRIVILEGES 

PUBLIC 

RAW 

RENAME 

RESOURCE 

REVOKE 

ROW 

ROWID 

ROWNUM 

ROWS 

RUN 


starting with ORACLE RDBMS V5 


starting with ORACLE RDBMS V5 
starting with ORACLE RDBMS V5 


starting with ORACLE RDBMS V5 
starting with ORACLE RDBMS V5 
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SELECT 

SESSION starting with ORACLE RDBMS V5 

SET 

SHARE 

SIZE 

SMALLINT 

SPACE 

START 

STATEMENT 

SUCCESSFUL starting with ORACLE RDBMS V5 

SYNONYM 

SYSDATE 

SYSSORT 

TABLE 

THEN 

TO 

TRIGGER 

UID 

UNION 

UNIQUE 

UPDATE 

USER 

USING 

VALIDATE 

VALUES 

VARCHAR 

VARGRAPHIC 

VIEW 

WHENEVER starting with ORACLE RDBMS V5 

WHERE 

WITH 
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APPENDIX B. DATA DICTIONARY TABLE DEFINITIONS 


Descriptions of the data dictionary tables are listed here for your reference; 
however, tables may change between ORACLE releases, so you should 
also consult the actual data dictionary information for the ORACLE re¬ 
lease running at your site. 


Appendix B. Data Dictionary Table Definitions / 209 














SQL> describe audit_access 
Name 


Null? Type 


USERID 


CHAR(30) 

USERHOST 


CHAR(240) 

TERMINAL 


CHAR(240) 

TIMESTAMP 

NOT 

NULL DATE 

OBJ$CREATOR 


CHAR(30) 

OBJ$NAME 


CHAR(30) 

ACTION 

NOT 

NULL NUMBER 

ACTION NAME 

NOT 

NULL CHAR(27) 

NEW$NAME 


CHAR(30) 

AUTH$PRIVILEGES 


CHAR(6) 

AUTH$GRANTEE 


CHAR(30) 

ALT 


CHAR(l) 

AUD 


CHAR(l) 

COM 


CHAR(l) 

DEL 


CHAR(l) 

GRA 


CHAR(l) 

IND 


CHAR(l) 

INS 


CHAR(l) 

LOC 


CHAR(l) 

REN 


CHAR(l) 

SEL 


CHAR(l) 

UPD 


CHAR(l) 

SESSIONID 

NOT 

NULL NUMBER 

ENTRYID 

NOT 

NULL NUMBER 

STATEMENT 

NOT 

NULL NUMBER 

RETURNCODE 

NOT 

NULL NUMBER 

SQL> describe audit_actions 



Name 

Null? Type 

ACTION 

NOT 

NULL NUMBER 

NAME 

NOT 

NULL CHAR(27) 
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SQL> describe audit_connect 
Name 


Null? Type 


USERID 

USERHOST 

TERMINAL 

ACTION_NAME 

TIMESTAMP 

LOGOFF$TIME 

LOGOFF$LREAD 

LOGOFF$PREAD 

LOGOFF$LWRITE 

LOGOFF$DEAD 

SESSIONID 

RETURNCODE 


CHAR(30) 
CHAR(240) 
CHAR(240) 
CHAR(7) 
NOT NULL DATE 
DATE 
NUMBER 
NUMBER 
NUMBER 
NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 


SQL> describe audit_dba 
Name 


Null? Type 


USERID 

USERHOST 

TERMINAL 

TIMESTAMP 

OBJ$CREATOR 

OBJ$NAME 

ACTION 

ACTION_NAME 

CONNECTS 

DBAS 

RESOURCES 

AUTHSGRANTEE 

NEWSNAME 

SESSIONID 

ENTRYID 

STATEMENT 

RETURNCODE 


CHAR(30) 
CHAR(240) 
CHAR(240) 
NOT NULL DATE 

CHAR(30) 
CHAR(30) 
NOT NULL NUMBER 
NOT NULL CHAR(27) 
CHAR(l) 
CHAR(l) 
CHAR(l) 
CHAR(30) 
CHAR(30) 
NOT NULL NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 
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SQL> describe aud1t_exists 
Name 


USERID 

USERHOST 

TERMINAL 

TIMESTAMP 

OBJ$CREATOR 

OBJ$NAME 

ACTION 

ACTION_NAME 

AUTH$PRIVILEGES 

AUTH$GRANTEE 

NEW$NAME 

SESSIONID 

ENTRYID 

STATEMENT 

RETURNCODE 


Null? Type 


CHAR(30) 
CHAR(240) 
CHAR(240) 
NOT NULL DATE 

CHAR(30) 
CHAR(30) 
NOT NULL NUMBER 
NOT NULL CHAR(27) 
CHAR(6) 
CHAR(30) 
CHAR(30) 
NOT NULL NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 
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SQL> describe audit_trail 

Name Null? Type 


USERID 

USERHOST 

TERMINAL 

TIMESTAMP 

0BJ$CREAT0R 

OBJ$NAME 

ACTION 

ACTION_NAME 

NEW$NAME 

AUTH$PRIVILEGES 

AUTH$GRANTEE 

SES$ACTIONS 

LOGOFF$TIME 

LOGOFF$LREAD 

LOGOFF$PREAD 

LOGOFF$LWRITE 

LOGOFF$DEAD 

COMMENT$TEXT 

SESSIONID 

ENTRYID 

STATEMENT 

RETURNCODE 


CHAR(30) 
CHAR(240) 
CHAR(240) 
NOT NULL DATE 

CHAR(30) 
CHAR(30) 
NOT NULL NUMBER 
NOT NULL CHAR(27) 
CHAR(30) 
CHAR(6) 
CHAR(30) 
CHAR(ll) 
DATE 
NUMBER 
NUMBER 
NUMBER 
NUMBER 
CHAR(240) 
NOT NULL NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 
NOT NULL NUMBER 


SQL> describe catalog 
Name 


TNAME 

CREATOR 

TABLETYPE 

CLUSTERID 

LOGBLK 

REQBLK 

IXCOMP 

REMARKS 


Null? Type 


NOT NULL CHAR(30) 
CHAR(30) 

NOT NULL CHAR(7) 
NUMBER 
NUMBER 
NUMBER 
CHAR(IO) 
CHAR(240) 
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SQl> describe 
Name 

clusters 

Null? 

Type 

CLCREATOR 



CHAR(30) 

CLNAME 


NOT NULL CHAR(30) 

LOGBLK 



NUMBER 

TCREATOR 



CHAR(30) 

TNAME 


NOT NULL CHART 30) 

TCLUSTERID 



NUMBER 

SQL> describe 

clustercolumns 



Name 


Null? 

Type 

CLCREATOR 



CHAR(30) 

CLNAME 


NOT NULL CHAR(30) 

CLCOL 


NOT NULL CHAR(30) 

TCREATOR 



CHAR(30) 

TNAME 


NOT NULL CHAR(30) 

TCOL 


NOT NULL CHAR(30) 

SQL> describe 

col 



Name 


Null? 

Type 

TNAME 


NOT NULL CHAR(30) 

COLNO 


NOT NULL NUMBER 

CNAME 


NOT NULL CHAR(30) 

COLTYPE 


NOT NULL CHAR(6) 

WIDTH 


NOT NULL NUMBER 

SCALE 



NUMBER 

NULLS 


NOT NULL CHAR(8) 

REMARKS 



CHAR(240) 

DEFAULTVAL 



CHAR(240) 
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SQL> describe columns 


Name 

Null? Type 

CNAME 

TNAME 

CREATOR 

COLNO 

COLTYPE 

WIDTH 

SCALE 

NULLS 

REMARKS 

DEFAULTVAL 

NOT NULL CHAR(30) 
NOT NULL CHAR(30) 
CHAR(30) 
NOT NULL NUMBER 

NOT NULL CHAR(6) 
NOT NULL NUMBER 
NUMBER 

NOT NULL CHAR(8) 
CHAR(240) 
CHAR(240) 


SQL> describe default_audit 
Name Null? Type 


ALT 

AUD 

COM 

DEL 

GRA 

IND 

INS 

LOC 

REN 

SEL 

UPD 


CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 


SQL> describe dtab 
Name 


TNAME 

REMARKS 


Null? Type 


CHAR(14) 
CHAR(64) 
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$QL> describe extents 

Name Null? Type 


NAME 


NOT NULL CHAR(30) 

1 YPb 


NOT NULL CHAR(7) 

WHICH 


NOT NULL CHAR(5) 

STORAGE 


NUMBER 

STARTING 


NOT NULL NUMBER 

ENDING 


NOT NULL NUMBER 

SQL> describe 

indexes 


Name 


Null? Type 

I NAME 


NOT NULL CHAR(30) 

ICREATOR 


CHAR(30) 

TNAME 


NOT NULL CHAR(30) 

CREATOR 


CHAR(30) 

COLNAMES 


NOT NULL CHAR(30) 

INDEXTYPE 


NOT NULL CHAR(IO) 

IORDER 


NOT NULL CHAR(4) 

COMPRESSION 


NOT NULL CHAR(IO) 

SEQ 


NOT NULL NUMBER 

CONCATID 


NUMBER 

SQL> describe 

partitions 


Name 


Null? Type 

PNAME 


NOT NULL CHAR(30) 

FNAME 


NOT NULL CHAR(239) 

ORABLOCKS 


NOT NULL NUMBER 

SQL> describe 

privatesyn 


Name 


Null? Type 

SNAME 


NOT NULL CHAR(30) 

CREATOR 


CHAR(30) 

TNAME 


NOT NULL CHAR(30) 

TABTYPE 


NOT NULL CHAR(7) 
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SQL> describe publicsyn 


Name 

Null? Type 

SNAME 

NOT NULL CHAR(30) 

CREATOR 

CHAR(30) 

TNAME 

NOT NULL CHAR(30) 

TABTYPE 

NOT NULL CHAR(7) 


SQL> describe sessions 


Name 

Null? 

Type 

USERID 


CHAR(30) 

USERHOST 


CHAR(240) 

TERMINAL 


CHAR(240) 

STATUS 


CHAR(7) 

LOGON 

NOT NULL 

DATE 

LOGOFF 


DATE 

LOGREAD 


NUMBER 

PHYSREAD 


NUMBER 

LOGWRITE 


NUMBER 

DEADLOCKS 


NUMBER 

SESSIONID 

NOT NULL 

NUMBER 

CLEANUP_ERROR 

NOT NULL 

NUMBER 

SQL> describe spaces 



Name 

Null? 

Type 

SNAME 

NOT NULL 

CHAR(30) 

DATA1 

NOT NULL 

NUMBER 

DATA2 

NOT NULL 

NUMBER 

EXT MAX 

NOT NULL 

NUMBER 

INDEX1 

NOT NULL 

NUMBER 

INDEX2 

NOT NULL 

NUMBER 

MAX EXT 

NOT NULL 

NUMBER 

PCT 

NOT NULL 

NUMBER 

PNAME 

NOT NULL 

CHAR(30) 
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SQL> describe storage 


Name 

Null? 

Type 

NAME 


CHAR(30) 

TYPE 


CHAR(7) 

WHICH 


CHAR(5) 

STORAGE 


NUMBER 

EXTENTS 


NUMBER 

SQL> describe synonyms 



Name 

Null? 

Type 

SNAME 

NOT NULL 

CHAR(30) 

SYNTYPE 


CHAR(7) 

CREATOR 


CHAR(30) 

TNAME 

NOT NULL 

CHAR(30) 

TABTYPE 

NOT NULL 

CHAR(7) 
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SQL> describe sysaudit_trail 


Name 

Null? Type 

SESSIONID 

NOT 

NULL NUMBER 

ENTRYID 

NOT 

NULL NUMBER 

STATEMENT 

NOT 

NULL NUMBER 

TIMESTAMP 

NOT 

NULL DATE 

USERID 


CHAR(30) 

USERHOST 


CHAR(240) 

TERMINAL 


CHAR(240) 

ACTION 

NOT 

NULL NUMBER 

RETURNCODE 

NOT 

NULL NUMBER 

0BJ$CREAT0R 


CHAR(30) 

0BJ$NAME 


CHAR(30) 

AUTH$PRIVILEGES 


CHAR(6) 

AUTH$GRANTEE 


CHAR(30) 

NEW$NAME 


CHAR(30) 

SES$ACTIONS 


CHAR(ll) 

SES$TID 


binary 

LOGOFFSLREAD 


NUMBER 

LOGOFF$PREAD 


NUMBER 

L0G0FF$LWRITE 


NUMBER 

L0G0FF$DEAD 


NUMBER 

LOGOFF$TIME 


DATE 

COMMENT$TEXT 


CHAR(240) 

SQL> describe syscatalog 



Name 

Null? Type 

TNAME 

NOT 

NULL CHAR(30) 

CREATOR 


CHAR(30) 

TABLETYPE 

NOT 

NULL CHAR(7) 

CLUSTERID 


NUMBER 

LOGBLK 


NUMBER 

REQBLK 


NUMBER 

IXCOMP 


CHAR(10) 

REMARKS 


CHAR(240) 
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SQL> describe 
Name 

syscolauth 

Null? 

Type 

GRANTOR 


NOT NULL CHAR(30) 

GRANTEE 


NOT NULL CHAR(30) 

CREATOR 


NOT NULL CHAR(30) 

TNAME 


NOT NULL CHAR(30) 

TIMESTAMP 


NOT NULL DATE 

COLNAME 


NOT NULL CHAR(30) 

UPD 


NOT NULL CHAR(l) 

SQL> describe 

syscolumns 



Name 


Null? 

Type 

CNAME 


NOT NULL CHAR(30) 

TNAME 


NOT NULL CHAR(30) 

CREATOR 



CHAR(30) 

COLNO 


NOT NULL NUMBER 

COLTYPE 


NOT NULL CHAR(6) 

WIDTH 


NOT NULL NUMBER 

SCALE 



NUMBER 

NULLS 


NOT NULL CHAR(8) 

REMARKS 



CHAR(240) 

DEFAULTVAL 



CHAR(240) 

SQL> describe 

sysextents 



Name 


Null? 

Type 

CREATOR 



CHAR(30) 

NAME 


NOT NULL CHAR(30) 

TYPE 


NOT NULL CHAR(7) 

WHICH 


NOT NULL CHAR(5) 

STORAGE 



NUMBER 

STARTING 


NOT NULL NUMBER 

ENDING 


NOT NULL NUMBER 
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SQL> describe sysindexes 


Name 

Null? Type 

I NAME 

NOT NULL CHAR(30) 

ICREATOR 

CHAR(30) 

TNAME 

NOT NULL CHAR(30) 

CREATOR 

CHAR(30) 

COLNAMES 

NOT NULL CHAR(30) 

INDEXTYPE 

NOT NULL CHAR(10) 

IORDER 

NOT NULL CHAR(4) 

COMPRESSION 

NOT NULL CHAR(10) 

SEQ 

NOT NULL NUMBER 

CONCATID 

NUMBER 


SQL> describe sysprogs 


Name 

Null? Type 

PROGRAM 

NOT NULL CHAR(30) 

AM ID 

NOT NULL NUMBER 

REVISION 

NUMBER 

STMNTS 

NOT NULL NUMBER 

CDATE 

DATE 

RDATE 

DATE 

LANGUAGE 

NOT NULL CHAR(30) 


SQL> describe sysstorage 
Name Null? Type 


CREATOR 

NAME 

TYPE 

STORAGE 

EXTENTS 


CHAR(30) 

CHAR(30) 

CHAR(7) 

NUMBER 

NUMBER 
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SQL> describe 
Name 

systaballoc 

Null? 

Type 

CREATOR 



CHAR(30) 

TNAME 



CHAR(30) 

D BLKS 



NUMBER 

D EXTS 



NUMBER 

I BLKS 



NUMBER 

I_EXTS 



NUMBER 

SQL> describe 

systabauth 



Name 


Null? 

Type 

GRANTOR 


NOT NULL CHAR(30) 

GRANTEE 


NOT NULL CHAR(30) 

CREATOR 


NOT NULL CHAR(30) 

TNAME 


NOT NULL CHAR(30) 

TIMESTAMP 


NOT NULL DATE 

ALT 


NOT NULL CHAR(l) 

DEL 


NOT NULL CHAR(l) 

NDX 


NOT NULL CHAR(l) 

INS 


NOT NULL CHAR(l) 

SEL 


NOT NULL CHAR(l) 

UPD 


NOT NULL CHAR(l) 

SQL> describe 

system_audit 



Name 


Null? 

Type 


CONNECT$ 

DBA$ 

NOT_EXISTS$ 

RESOURCE$ 


CHAR(3) 

CHAR(3) 

CHAR(3) 

CHAR(3) 


222 / The ORACLE Database Administrator's Guide 













SQL> describe sysuserauth 
Name 


Null? Type 


USERID 

USERNAME 

PASSWORD 

TIMESTAMP 

CONNECTAUTH 

DBAAUTH 

RESOURCEAUTH 


NOT NULL NUMBER 
CHAR(30) 
CHAR(30) 
NOT NULL DATE 

CHAR(l) 

CHAR(l) 

CHAR(l) 


SQL> describe sysuserlist 


Name 


Null? 

Type 

USERID 

USERNAME 

TIMESTAMP 

CONNECTAUTH 

DBAAUTH 

RESOURCEAUTH 


NOT NULL 

NOT NULL 

NUMBER 

CHAR(30) 

DATE 

CHAR(l) 

CHAR(l) 

CHAR(l) 

SQL> describe 
Name 

sysviews 

Null? 

Type 

VIEWNAME 

VCREATOR 


NOT NULL CHAR(30) 
CHAR(30) 

SQL> describe 
Name 

tab 

Null? 

Type 

TNAME 

TABTYPE 

CLUSTERID 


NOT NULL CHAR(30) 
NOT NULL CHAR(7) 
NUMBER 

$QL> describe 
Name 

taballoc 

Null? 

Type 

TNAME 

D BLKS 

D EXTS 

I BLKS 

I EXTS 



CHAR(30) 

NUMBER 

NUMBER 

NUMBER 

NUMBER 
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SQL> describe tabquotas 

Name 

Null? Type 

TNAME 

NOT NULL CHAR(30) 

DINI 

NOT NULL NUMBER 

DINC 

NOT NULL NUMBER 

DMEXTNT 

NOT NULL NUMBER 

I INI 

NOT NULL NUMBER 

I INC 

NOT NULL NUMBER 

IMEXTNT 

NOT NULL NUMBER 

PFREE 

NOT NULL NUMBER 

PID 

NUMBER 

RBA 

NUMBER 

TBL 

NUMBER 

TIME 

DATE 

SQL> describe table_audit 


Name 

Null? Type 

CREATOR 

CHAR(30) 

TNAME 

NOT NULL CHAR(30) 

TABLETYPE 

NOT NULL CHAR(7) 

ALT 

CHAR(3) 

AUD 

CHAR(3) 

COM 

CHAR(3) 

DEL 

CHAR(3) 

GRA 

CHAR(3) 

IND 

CHAR(3) 

INS 

CHAR(3) 

LOC 

CHAR(3) 

REN 

CHAR(3) 

SEL 

CHAR(3) 

UPD 

CHAR(3) 


SQL> describe views 

Name Null? Type 


VIEWNAME 

VIEWTEXT 


NOT NULL CHAR(30) 
NOT NULL LONG 
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SQL> describe dblinks 


Name 

Null? 

Type 

NAME 


CHAR(30) 

TYPE 


CHAR(7) 

HOST 


CHAR(240) 

USERID 


CHAR(30) 

SQL> describe sysdblinks 

Name 

Null? 

Type 

OWNER 


CHAR(30) 

NAME 


CHAR(30) 

HOST 


CHAR(240) 

USERID 


CHAR(30) 
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APPENDIX C. LIMITS 


This appendix lists limits, such as the maximum number of characters al¬ 
lowed per title, which you may run into in various ORACLE applications. 
In most cases the limits are maximums; exceptions are noted. These limits 
apply to ORACLE running under all operating systems; however, there are 
some exceptions, and you should refer to the guide xxx to see if any exist 
for your system. 


WHAT 

LIMIT 


Tables 

operating system specific 


- about 9,500 in VMS. 

Tables/cluster 

32 


Columns/table 

254 (255 is ROWID) 


Chars/column (type CHAR) 

240 chars 


Chars/column (type LONG) 

65,535 chars 


Digits significance 

42 digits plus sign 


Exponent range on numbers 

10 exp (+/- 128) 


Records/table 

0/S specific 



VMS: However many can 
fit in 2**29 blocks 

Blocks/table 

2**29 blocks 


Files/database 

0/S specific 


Partitions/database 

0/S specific 


Files/partition 

0/S specific 


Size of database 

2**29 disk blocks of 
si ze 

any 

Chars/concatenated key 
separators) 

240 chars (including 

1 byte 

Indexed columns/table 

0 to n, if table has 

n cols. 

Bytes/row 

254 cols x 240 chars 

+ 65535 = 126KB 

Chars/SQL statement 

8,000 
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APPENDIX D. SUMMARY OF INIT.ORA PARAMETERS 


Notes: 

1. 0/S indicates that the value varies by operating system. 

2. Parameter values distributed on release media may differ from default 
values (for distributed values see the Installation and User's Guide for 
your operating system). 
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PARAMETER 

NAME 

DEFAULT 

VALUE 

OK TO 
ALTER? 

IMPACT 
ON SGA 

COMMENTS 

AI BUFFERS 

3 

no 

none 

[Not used] Number of 
after image buffers. 

AFTER_IMAGE 

null 

yes 


Name of after image files. 

If not null, enables AIJ. 

May appear more than once. 

AI_FILE_SIZE 

0 

yes 


Size of AIJ files in ORACLE blocks. 
If: Then: 

0 Use files in AFTER_IMAGE 

>0 Size in K-bytes to 

create journal files. 

AI_WARN_PCNT 

0 

yes 

' 

Message is sent to operator 
console when AIJ file is this % full 
[not enabled] 

AUDIT_TRAIL 

0 

yes 

- 

If non-zero enables auditing. 

If zero, disables auditing. 

BEFORE_IMAGE 

0/S 

yes 

- 

Name of before image (BI) file. 

BI_BUFFERS 

0/S 

no 

some 

Number of before image buffers. 

BI_HIGH 


yes 

- 

Last block in BI file for in¬ 
stance using this INIT.ORA file 

BI_L0W 


yes 

- 

First block in BI file for in¬ 
stance using this INIT.ORA file 

BLOCK_SIZE 

0/S 

no 

some 

Bytes in an ORACLE database block. 

BUFFERS 

50 

yes 

high 

Number of data buffers cached in 
memory. 

BUFF_HASH_BKTS 

8 

no 

low 

Number of entries in hash table 
used to find ORACLE buffers. 
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PARAMETER 

NAME 

DEFAULT 

VALUE 

OK TO 
ALTER? 

IMPACT 
ON SGA 

COMMENTS 

CLUSTERS 

20 

yes 

low 

Number of cached cluster definitions 

COLUMNS 

CONSOLE 

350 

yes 

some 

Number of cached column definitions, 
[not used.] 

CONTEXT_INCR 

4096 

bytes 

yes 

- 

Default context increment size. 

Range is 1024-32768 bytes. 

CONTEXT_SIZE 

4096 

bytes 

yes 

- 

Default context size in bytes. 

Range is 1024-131072 bytes. 

DATABASE 

0/S 

yes 

- 

Name of primary database (DB) file. 

DETACHED DUMPS 

0/S 

yes 

- 

Name of directory where dumps 

ENQUEUES 

5 times yes 
PROCESSES 

some 

Number of entries 

FILES 

5 

yes 

some 

Number of database files open in SGA 

FIXED_DATE 

nul 1 

yes 

- 

Date for ORACLE'S internal SYSDATE. 

INSTANCES 

16 

yes 

- 

Number of Instances per shared 
partition system. Max: 16. 

INSTANCE_NAME 

- 

no 

- 

Name of instance running this 
INIT.ORA file. 

LANGUAGE 


yes 

— 

An alphanumeric string of up to 

15 characters, returned in 

USERENVCLANGUAGE'). 

0PEN_CURS0RS 

50 

yes 

some 

Number of cursors each process is 
allowed to open. Range is 10-255. 

OPEN_LINKS 

4 

yes 

some 

Number of database links in 
simultaneous use by a user's 
session. 

PROCESSES 

25 

yes 

some 

Number of concurrent processes. 
Maximum is 0/S dependent. 
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PARAMETER DEFAULT OK TO IMPACT 


NAME 

VALUE ALTER? 

ON SGA 

COMMENTS 

READ_BLKS_REQ 

lesser no 
of 10 or 
READ_BLKS_TOT 


Number of blocks that may be 
requested in a single read request. 
Range is 0-255 blocks. 

READ_BLKS_TOT 

1/2 of no 
BUFFERS 

- 

Number of blocks that may be in 
outstanding background read requests 

READ_REQUESTS 

greater no 
of 5 or 
PROCESSES 

low 

Number of outstanding background 
read requests. 

SINGLE_PROCESS 

0 yes 

- 

If zero enables multi-user system. 

If nonzero enables single-user system 

SORT_AREA_SZ 

0/S yes 


Size in bytes of in memory work 
areas. Range and default are 0/S 
dependent. 

SORT_FINAL_RA 

0/S no 


Readahead depth factor during 
final sort passes. 

SORT_MERGE_RA 

0/S no 

- 

Readahead depth factor during 
intermediate sort passes. 

S0RT_P00L_SZ 

- 

- 

[no longer used.] 

SORT_SPCMAP_SZ 

0/S yes 

0/S 

Size in bytes of sort spacemap in 
context area. Range and default are 
0/S dependent. 

SORT_READ_FAC 

no 

0/S 

Multi-block read factor for sorting. 

SQL 

SQL.ORA yes 

- 

Name of SQL file to run during 
initialization. 

TABLE_ACCESSES 

fn of 

PROCESSES 

some 

Number of distinct tables in use. 
at one time. Range is 8-208. 

TABLE_HANDLES 

8 times 
PROCESSES 

some 

Number of simultaneous table uses 
at one time on one table. Max is 24. 
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PARAMETER 

NAME 

DEFAULT OK TO 
VALUE ALTER? 

IMPACT 
ON SGA 

COMMENTS 

TABLE_HSH_BKTS 

1-32 

depending on 
TABLE_ACCESSES 

some 

Entries in has table used to 
find table access entries. 

TABLE_NAMES 

80 yes 

some 

Number of names (table, view, and 
synonym) cached. 

TABLES 

50 yes 

some 

Number of table definitions cached 
Min is 10. 

TEMP_TABLES 

1/10 of yes 
lesser of 

TABLE HANDLES 
or TABLE_ACCESSES 

Number of temporary tables 

ORACLE maintains. 

TRANSACTIONS 

5 times yes 
PROCESSES 

some 

Number of concurrent transactions. 

USERINIT 

null yes 

- 

Name of file to run after file 
specified by SQL parameter. 

USERS 

30 yes 

some 

Number of usernames cached. 

USER_DUMPS 

0/S 

- 

Name of directory for user dumps. 


Appendix D. Summary of INIT.ORA Parameters / 233 













234 / The ORACLE Database Administrator's Guide 









APPENDIX E. TERMINAL FUNCTION CODES FOR USING CRT 


This appendix contains the function code and name of the keyboard func¬ 
tions for SQL + Forms program IAP and SQL*Menu. You might want to 
fill in the keys in use at your installation. 
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SQL*FORMS (IAP) CODES 


FU FNAME 


AQ ABORT QUERY 
BM SELECT BLOCK BY MENU 
CA CLEAR ALL 
CB CLEAR BLOCK 
CF CLEAR (END OF) FIELD 
CM CHANGE CHARACTER MODE 
CQ COUNT QUERY HITS 
CR CREATE RECORD 
CT COMMIT TRANSACTION 
D DELETE RECORD 
DC DELETE CHARACTER 
DE DISPLAY LAST ERROR 
DF DUPLICATE FIELD 
DK DISPLAY FUNCTION KEYS 
DR DUPLICATE RECORD 
EQ ENTER A QUERY 
H HELP FIELD 
LV LIST FIELD VALUES 
ML MOVE CURSOR LEFT 
MR MOVE CURSOR RIGHT 
NB NEXT BLOCK 
NF NEXT FIELD 
NK NEXT PRIMARY KEY FIELD 
NR NEXT RECORD 
NS NEXT RECORD SET 
P PRINT FUNCTION 
PB PREVIOUS BLOCK 
PF PREVIOUS FIELD 
PR PREVIOUS RECORD 
Q EXECUTES QUERY FUNCTION 
R REDISPLAY SCREEN 
RR RELEASE RECORD 
X EXIT IAP 
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SQL*MENU CODES 


FU FNAME 

NF NEXT FIELD 

PF PREVIOUS FIELD 

CF CLEAR FIELD 

EM ENTER MENU PARAMETERS 

EA ENTER APPLICATION PARAMETERS 

EO ENTER AND EXECUTE O.S COMMAND 

PM PREVIOUS MENU 

MM GOTO MAIN MENU 

AM GOTO APPLICATION MENU 

HO HELP (OPTION) 

HI HELP (MENU) 

CM CHANGE CHARACTER MODE 
CD CHANGE DEBUG MODE 
X EXIT 

RU REDEFINE USERNAME/PASSWORD 
RS REDISPLAY SCREEN 
SB SHOW BACKGROUND MENU 
TM TERMINATE INPUT ON FORM 
ML MOVE CURSOR LEFT 
MR MOVE CURSOR RIGHT 
MU MOVE CURSOR UP 
MD MOVE CURSOR DOWN 
DC DELETE CHARACTER 
DF DISPLAY FUCTION KEYS 
El ENTER AND EXEC 1 O.S. CMD. 


BO 

BG. 

MENU 

OPTION 

NR 

1 . 

B1 

BG. 

MENU 

OPTION 

NR 

2. 

B2 

BG. 

MENU 

OPTION 

NR 

3. 

B3 

BG. 

MENU 

OPTION 

NR 

4. 

B4 

BG. 

MENU 

OPTION 

NR 

5. 

B5 

BG. 

MENU 

OPTION 

NR 

6. 

B6 

BG. 

MENU 

OPTION 

NR 

7. 

B7 

BG. 

MENU 

OPTION 

NR 

8. 

B8 

BG. 

MENU 

OPTION 

NR 

9. 

B9 

BG. 

MENU 

OPTION 

NR 

10 
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APPENDIX F. TERMINAL DEFINITIONS PROVIDED BY ORACLE 
CORPORATION 


Oracle Corporation provides terminal definitions for the following termi¬ 
nals. 

• D200 

• D410 

• D605x 

• GG 

• GIGI 

• IBM3270 

• OWL 

• PC 

• VI 3x0 

• VK100 

• VT52 

• VT100 

• VT102 

• VT200 

• VT220 

These names correspond to the file name portion of the .CRT file. The 
actual CRT files on the distribution tape for any given operating system 
may vary, but will include definitions for more commonly used terminals 
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GLOSSARY 

address (row): See ROWID. 

after image journalling: A ORACLE DBA utility 
used for database recovery in the event of a serious 
problem such as media failure or head crash. The 
journal is a physical record of all changes made to 
the database and can be applied to a backup copy 
of the database to "roll forward" the data to the 
state it was in previous to the failure. 

asynchronous rcadahead: An ORACLE process 
(ARH) which reads data blocks from the database 
into the SGA for queries doing full table scans, in 
order to speed query time. 

asynchronous terminal: A terminal which trans¬ 
mits and receives data a character at a time (as 
opposed to a field or screen at a time). 

auditing: General term for ORACLE installation 
and data dictionary features which allow the DBA 
and ORACLE users to track usage of the data¬ 
base. The auditing information is stored in the 
data dictionary and SQL statements are used to 
control which information is stored. For example, 
all attempts to update a table's data can be re¬ 
corded, or only unsuccessful attempts. Or, all 
logins to ORACLE can be recorded, or unsuc¬ 
cessful attempts to do DBA activities. The DBA 
can determine default auditing activity. 

B*-trce: A type of indexing algorithm used by 
ORACLE to create and store indexes. 

before image file: A file (also called BI file) used 
to store a copy of each modified block during an 
update operation. This file guarantees that trans¬ 
actions are not made permanent until they are 


complete, consistent, and committed by the user. 
It also supports read consistency. Each system 
has only one BI file. 

block: Basic unit of storage (physical and logical) 
for all ORACLE data. The number of blocks al¬ 
located per ORACLE table depends on the space 
definition in effect for that table's creation. The 
ORACLE block size varies by operating system. 

block mode terminal: See synchronous terminal. 

CCF: An ORACLE utility available on many 
but not all operating systems, used by the DBA 
to create and ready the database and before image 
files. Stands for Create Contiguous File. 

chained block: A second or subsequent 
ORACLE block designated to store table data, 
when the originally allocated block has run out of 
space and rows in that block expand due to up¬ 
dates. More often used for table data, but index 
data can also be chained. More chained blocks 
will have an impact on performance, so if they 
occur, the PCTFREE space definition parameter 
may be set too low. 

CHAR datatype: An ORACLE datatype which 
stores character strings to a maximum size of 240 
characters. 

cluster: A means of storing data from multiple 
tables together, when the data in those tables 
contains common information and is likely to be 
accessed together. A means of storing data and 
improving performance, clustering has no impact 
on how users word SQL statements. 
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cluster key: The column or columns which clus¬ 
tered tables have in common, and which is chosen 
as the storage/access key. For example, two ta¬ 
bles, BMP and DEP T, might be clustered on a 
column DEPTNO. 

cold start: Another term for starting an 
ORACLE database for the first time; more fre¬ 
quently called "initializing a database". Invoking 
the IOR program with the INIT option (executing 
IOR INIT). * 

commit: To make permanent changes to data 
(inserts, updates, deletes). Before the changes are 
stored, both the old and new data exist so that the 
changes can be stored or the data can be restored 
to its prior state. At commit time, all data which 
is a part of the transaction (or logical unit of 
work) is committed. 

compressed index: An index for which only 
enough index information is stored to identify 
unique index entries; information which an index 
shares with the previous or following key is 
"compressed" (truncated) and not stored, to reduce 
the storage overhead required by an index. Con¬ 
trast with noncompressed indexes. 

concatenated index: An index which is created 
on more than one column of a table. Can be used 
to guarantee that those columns are unique for 
every row in the table (as for area code/phone 
number). Can be created either compressed or 
noncompressed and on any combination of a ta¬ 
ble's columns. 

context area: A work area where ORACLE 
stores the current SQL statement, and if the 
statement is a query, then the result's column 
headings and one row of the result. 

CR T file: A file which maps terminal keys to 
application functions (such as Clear Screen or Go 
To Next Field). A different CRT file should exist 
for each class of terminals which behave essentially 
alike. 

cursor (I): Synonym for context area. 


cursor (2): A marker such as a blinking square 
or line, which marks your current position on a 
CRT screen. 

cursor coordinates: The coordinates of the hori¬ 
zontal and vertical position of a cursor on a 
screen. Coordinate labels and ranges vary by ter¬ 
minal type. 

data control (DCL) statements: One category of 
SQL statements — for statements which control 
access to the data and to the database. Examples 
are GRANT CONNECT .... GRANT SELECT 
UPDATE ON .... and REVOKE DBA. .. The 
other categories are data definition (DDL) and 
data manipulation (DML). 

data definition (DDL): One category of SQL 
statements - for statements which define (GRE¬ 
AT E) or delete (DROP) database objects. Ex¬ 
amples are CREATE VIEW .... CREATE 
TABLE ..., CREATE INDEX .... and DROP 
TABLE ..., RENAME I ABLE .... The other 
categories arc data control (DCL) and data ma¬ 
nipulation (DML). 

data definition locks: I xicks placed on the data 
dictionary during changes to the structures (defi¬ 
nitions) of database objects (such as tables, in¬ 
dexes, views, clusters) so that those changes occur 
with no negative impact on the database data. 
These locks appear in ODS as DDL locks and 
there arc three kinds: dictionary operation lock, 
dictionary definition lock, and table definition 
lock. 

data dictionary: A comprehensive set of tables 
and views owned by the DBA users SYS and 
SYSTEM, which is installed when ORACLE is 
initially installed, and is a central source of infor¬ 
mation, for the ORACLE RDBMS itself and for 
all users of ORACLE. I he tables are automat¬ 
ically maintained by ORACLE. 

data manipulation (DML): One category of SQL 
statements - for statements which query and up¬ 
date the actual data. Examples are SELECT 
INSERT .... DELETE .... UPDATE. The other 
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categories are data definition (DDL) and data 
control (DCL). 

data segment: The storage which is allocated to 
the data of a table, as compared to storage allo¬ 
cated to the indexes on a table. The data segment 
is made up of an initial data extent, and zero or 
more incremental data extents. The size and 
number of these extents is determined by the space 
definition in effect during table creation. 

deadlock: A situation which can occur in a 
multi-user system when two users are each con¬ 
tending for resources locked by the other user, and 
neither user can obtain the necessary resource to 
complete his work. ORACLE identifies deadlocks 
and resolves them by rolling back the work of the 
user with the least work pending. 

default CRT: The terminal which corresponds to 
the DEFAULT.CRT file. 

device: A display terminal (CRT) such as an 
IBM 3270, DEC VT100 or VT220. 

dictionary definition locks: A shared lock owned 
by users parsing DML statements, or an exclusive 
lock owned by users doing DDL commands, to 
prevent a table from being altered while the dic¬ 
tionaries are queried. There may be many such 
locks concurrently. 

dictionary operation locks: An exclusive lock in 
effect while the dictionary is being updated. There 
is only one and it is always exclusive. 

enqueues: A resource which monitors lock re¬ 
quests. Each process requiring a lock on a data¬ 
base object must obtain an enqueue for it. The 
maximum number of lock requests is determined 
by the INIT.ORA parameter ENQUEUES. 

exclusive mode locking: A mode of locking tables 
to assure that one process is the only process up¬ 
dating a table's data. No other process can obtain 
a lock on the table until the exclusive lock is re¬ 
leased. 


executable statement: A SQL statement or 
programmatic interface call which generates code 
and an actual call to the database. Includes all 
SQL DML, DDL, and DCL statements. 

export: (noun) The ORACLE utility used to 
store ORACLE database data in export format 
files for later retrieval into an ORACLE database 
via Import, (verb) To use the Export utility to 
write selected table data to an export file. 

extent: A run of contiguous blocks in a database 
file which is allocated either for a table's data seg¬ 
ment or index segment. The first extent allocated 
is called the initial extent, and each subsequen ex¬ 
tent of blocks is called an increment extent. The 
number of blocks per extent is controlled by a 
space definition. 

extent block: The first block in the initial data 
or index extent, which contains administrative in¬ 
formation about each extent allocated to the table. 
There are three blocks of overhead per table (two 
for data and one for index); the extent block is the 
first data and first index block. 

file: As used by SQL and ORACLE, a physical 
file which constitutes either a whole partition or a 
portion of a partition. A storage area used to store 
all database data. A database must have one 
physical file (in the SYSTEM partition) but may 
have many files in multiple partitions. 

foreign key: A column (or combination of col¬ 
umns) in one table which is not a key in that par¬ 
ticular table, but is a key elsewhere (usually in 
another table). A foreign key column uses the 
same domain values as a column used as a key. 
Foreign keys are used widely for relating data in 
multiple tables using joins. 

function code: An ORACLE defined set of two- 
letter codes which correspond to the functions re¬ 
quired by ORACLE products. Stored in database 
table SYSTEM.FUNCTIONS. 

import: (noun) The ORACLE utility used to re¬ 
trieve ORACLE database data found in export 
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format files into an ORACLE database, (verb) 
To use the Import utility to move data from an 
export file into database table(s). 

index: A general term for an ORACLE/SQL 
feature used primarily to speed execution and im¬ 
pose uniqueness upon certain data. Provides a 
faster access method to one table's data than doing 
a full table scan. There are several types of in¬ 
dexes; see concatenated , compressed , noncom- 
pressed , unique. 

index segment: The storage which is allocated for 
the indexes on a table, as compared to storage al¬ 
located to the data in a table. The index segment 
is made up of one initial index extent, and proba¬ 
bly zero or more incremental index extents. The 
size and number of these extents is determined by 
the space definition in effect during table creation. 

initialization: An initial preparing of a database, 
always done when installing a database system for 
the first time. Invoked by using IOR INIT. Any 
existing user data is lost, and initial database tables 
are set up. 

instance: A member of a shared partition data¬ 
base system, as in an ORACLE cluster running 
on a VAX Cluster. Though the instances all share 
the same data in one database, they each run 
semi-independently, with their own parameter files 
and portions of shared before image files. 

INIT.ORA: A database system parameter file, 
which contains several settings and filenames used 
when a system is started using the IOR program. 

IOR program: An ORACLE DBA utility pro¬ 
gram used to initialize an ORACLE system, and 
to start and stop it. Options include running 
ORACLE shared when there are instances sharing 
a database file and starting ORACLE so that only 
DBAs can access the database. 

Julian date: A means of converting date data so 
that every date can be expressed as a unique inte¬ 
ger. Can be obtained by using the format mask 
T with functions on date data. 


key: The column or combination of columns in 
one table which can be used to uniquely identify 
a row. The column(s) forming a key are usually 
indexed. 

locks: General term for several types of protective 
mechanisms used by ORACLE to protect the 
structure of data objects (table names, column 
definitions, usernames, for example) and the in¬ 
tegrity of the data. Locks are used so that no 
change to data in one place damages data in an¬ 
other. 

LONG datatype: An ORACLE datatype which 
allows very long strings of character data. LONG 
data may be up to 65,535 characters long. 

LONG RAW datatype: An ORACLE datatype 
similar to the LONG datatype, but makes no as¬ 
sumptions about the type of data (for example, 
ASCII or EBCDIC). Intended for byte-oriented 
data up to 65,535 bytes long. 

noncomprcsscd index: An index of one or more 
columns (that is it may be concatenated) in which 
all the index data is stored in the index. Can allow 
for faster query time if all the data requested is 
stored in the index. Contrast to compressed in¬ 
dexes. 

non-displayable characters: Command strings 
used to achieve certain screen functions (such as 
Clear Screen or Move Cursor Right) which are 
not displayed on the screen. 

NUMBER datatype: An ORACLE datatype in¬ 
tended to hold numeric data. 

OPSS logins: A type of ORACLE username in 
which OPSS is prefixed to the operating system 
account or id, to simplify logging in to ORACLE 
from that id. 

parse: The mapping of a SQL statement to a 
cursor. At parse time several validation checks are 
made, such as do all referenced objects exist, are 
grants proper, and is statement syntax correct? 
Also, decisions regarding execution and optimiza¬ 
tion arc made, such as which indexes will be used. 
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partition: A logical storage unit of an ORACLE 
database. Every database always contains a SYS¬ 
TEM partition, but may contain additional parti¬ 
tions. A partition consists of one or more physical 
files. 

pass number: The number of times that all the 
blocks in the BI file have been cycled through. 
Though it appears in the BI screen in ODS, it is 
not particularly useful to users. 

percent free: A portion of the data block which 
is not filled by rows as they are inserted into a ta¬ 
ble, but is reserved for later updates made to the 
rows in that block. The actual percent is deter¬ 
mined by the PCTFREE value in the space defi¬ 
nition used at table creation. 

predicate clause: A seletion criteria clause based 
on one of the operators (=,! = , IS, IS NOT, > , 

> = , < , < = ) and containing no AND, OR, or 
NOT. 

public synonym: A synonym for a database object 
which the DBA has created for use by all 
ORACLE users. 

RBA: Relative Block Address - the number of 
an ORACLE block within a partition. The RBA 
is the last part of the ROW ID. 

RAW datatype: An ORACLE datatype similar 
to the CHAR datatype, except it stores uninter¬ 
preted bytes rather than characters. 

read consistency: Feature whereby a SQL query 
always sees a snapshot of a table as it existed at the 
start of query execution even while others may be 
modifying the table. 

rollback: To undo changes made to the database 
during a transaction or logical unit of work; op¬ 
posite of commit. 

row-level locking: Synonymous with Share Up¬ 
date mode locking, a type of locking in which up¬ 
dates to data occur through locking rows in a table 
and not the entire table. 


ROW1D: A pseudo-column for every row in the 
database, which contains the address of each row, 
and thus is unique for every row. The fastest 
means of accessing any row, the ROW ID contains 
three parts: the partition number, the number of 
the block within the partition, and the number of 
the row within the block. 

row sequence number: A number assigned to a 
row as it is inserted into a data block for a table. 
This number is also stored as row overhead and 
forms a part of the ROWID. 

segments: The storage space available for a ta¬ 
ble's data or indexes. Every table has two seg¬ 
ments — one for data and one for all its indexes 
Each segment is made up of extents, which are 
made up of blocks. The space definition controls 
how many extents are possible, or the size of the 
segments. 

server system: Configuration of ORACLE when 
a remote user accesses ORACLE via SQL + Net. 

share mode locking: A mode of locking which 
guarantees that data will not change while a proc¬ 
ess is querying it. This mode must be invoked 
explictly with the LOCK TABLE in SHARE 
MODE statement. 

share update mode: Synonymous with row-level 
locking, a type of locking in which updates to data 
occur through locking rows in a table and not the 
entire table. 

shared partition system: An ORACLE config¬ 
uration where ORACLE./ systems on multiple 
network nodes share the same database files. Each 
node is called an instance. 

space definition: A database object used to con¬ 
trol space allocation for a table's data. A defi¬ 
nition, which can be used by any table, contains 
two main parts: specifications for the data seg¬ 
ments , and specifications for index segments. 

synchronous terminal: A terminal which trans¬ 
mits and receives data a field or a screen at a time 
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(as opposed to a character at a time). Also called 
block mode terminals. 

SYS (ORACLE user): One of the DBA users 
which is created when database system is installed 
and initialized (the other is SYSTEM.) SYS owns 
most of the data dictionary tables, while SYSTEM 
owns the views created on those base tables. 

SYSTEM (ORACLE user): One of the DBA 
users which is created when database system is 
installed and initialized (the other is SYS.) While 
SYS owns most of the data dictionary tables, 
SYSTEM owns the views created on those base 
tables. 

SYS I EM (ORACLE partition): The original 
and only partition which exists in a newly installed 
system. Every database system must have a 
SYSTEM partition, and that partition must have 
at least one file allocated to it. 

system global area (SGA): A shared storage area 
in main or virtual memory (depending on your 
operating system) which is allocated by the 10 R 
program and is the center of ORACLE activity 
while the database is running. The size of the 
SGA (and performance of the system) depend on 
the values of the variable INIT.ORA parameters. 

tabic locks: A general category of locks which 
protect data and updates to data by concurrent 
users. Include locks in share mode, exclusive 
mode and share update mode. Appear in ODS 
with either prefix DML or ROW. 

table definition locks: Locks held by processes 
either referencing a table in a SQL statement (lock 
is held shared) or modifying a table's definition 
(lock is held exclusive). Among the most com¬ 
mon locks to appear in ODS (with prefix DDL). 

temporary tables: Tables created by ORACLE in 
order to execute a user's SQL statement. Fre¬ 


quently required to order data, the tables may be 
required by SQL statements including DIS¬ 
TINCT, ORDER BY, or GROUP BY clauses. 
Created, maintained, and dropped automatically 
by ORACLE, the average number that exist is set 
by the TEMP_TABI .ES parameter in 
INIT.ORA. 

terminal definition: A terminal which has a cor¬ 
responding .CRT file. The .CRT file contains in¬ 
formation needed by ORACLE to establish the 
correct functions for terminal keys. 

transaction: In ORACLE, a transaction is 
equivalent to a logical unit of work , which includes 
all SQL statements since you either logged on, last 
committed, or last rolled back your work. Thus, 
a transaction can encompass one SQL statement 
only or numerous SQL statements. 

unique index: An index (either compressed or 
noncompressed) which imposes uniqueness on 
each value it indexes. The index may be one sin¬ 
gle column or concatenated (multiple columns). 

unit of work: In ORACLE, a transaction is 
equivalent to a logical unit of work , which includes 
all SQL statements since you either logged on, last 
committed, or last rolled back your work. Thus, 
a transaction can encompass one SQL statement 
only or numerous SQL statements. 

variable parameters: Certain parameters which 
may be set in the INIT.ORA parameter file which 
will impact the size of the system global area 
(SGA). If these parameters are increased, the size 
required by the SGA also increases. 

warm start: To start an ORACLE database any¬ 
time but the first (at which time it is both started 
and initialized). To execute the 10R program 
with option WARM — the normal way of starting 
a database. 
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syntax for 185 
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After image file 9, 27 
filling up 28 
size of 28 
writing to 11 
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DATABASE option 64 
DEBUG option 64 
enabling 27, 59, 61 
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INIT.ORA parameters and 62 
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UNTIL option 65 

AFTER IMAGE parameter 27, 61, 62, 63 
AI BUFFERS parameter 27 
AIJFILEJSIZE parameter 28, 61, 62, 63 
AI WARN PCNT parameter 28, 61, 62, 63, 67 


AIJ command 64 
AIJ utility 5 
Allocation of space 111 
ALTER PARTITION statement 99 
American National Standards Institute 
(ANSI) 4 
Archiving data 5 
ARII process 10, 11, 21, 33, 138 
Array processing 181 
ASCII data 73, 118, 123 
Asynchronous devices 72, 80 
Asynchronous read requests 138 
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ATT REVRS terminal attribute 78 
ATT UNDER terminal attribute 78 
Attributes, terminal 
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numbered 78 

ATT1 (terminal attribute) 76 
attributes 76 

ATT 12 (terminal attribute) 76 
ATT 12 3 (terminal attribute) 77 
ATT 13 (terminal attribute) 77 
ATT2 (terminal attribute) 76 
ATT2 3 (terminal attribute) 77 
ATT3 (terminal attribute) 77 
Audit (AUD) lock 138 
AUDIT statement 

for DBA operations 197 
syntax for 194 
Audit trail 138 

AUDIT_TRAIL data dictionary view 95, 193, 
199 

AUDIT TRAIL parameter 28,194 
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data dictionary information 198 
DBA options 193 
enabling 28, 193, 194 
user options 193 
Auditing options 194 

AUDIT ACTIONS view 198 
BY ACCESS 195 
BY SESSION 195 
CONNECT 197 
DBA 197 
DBA-only 194 
NOT EXISTS 197 
RESOURCE 197 
setting system defaults 194 
WHENEVER NOT SUCCESSFUL 196 
WHENEVER SUCCESSFUL 196 
Automatic logon 188 
passwords for 188 
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Base line (display terminal) 75 
Before image (BFI) lock 138 
Before image buffers 22, 28 
Before image file 8, 43, 134, 136 
BIW writing to 134 
during warm start 21 
ending block 29 
enlarging 19 
enlarging (replacing) 135 
locks on 138 
monitoring 135 
name of 9, 28 
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writing to 11 

Before image screen (ODS) 46, 135 
BEFORE IMAGE parameter 28 
BI BUFFERS parameter 28 
BI IIIGH parameter 29 
BI LOW parameter 29 
Binary data 123 
BIW process 10, 11, 21, 134 
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Block mode devices 72 
Block, ORACLE 
number (ID) 125 
size 113 

BLOCK SIZE parameter 29 
Blocks, ORACLE 
addresses 147 
header 113 

in before image file 134 
listing available 101 
per read request 33 
requested by ARH 33 
Bold 77 

BUFFIIASIIBKTS parameter 29 
Buffers 

clearing 29 
locks on 138 

BUFFERS parameter 27, 29 
Bug fixes 8 

BWR process 10, 11,21 
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Cache buffers (CBM) lock 138 
Cartesian products 180 
CATALOG data dictionary view 93 
CATALOG.OR A file 37, 91, 93, 94 
CCF utility 21, 100 
syntax of 100 

Chained blocks 107, 115, 126, 166, 168 
Changing passwords 189 
CHAR datatype 118 
CLEAR option (IOR) 20 
Clearing ORACLE 20, 23 
CLN process 10, 11, 21 
Cluster cache 30 
Cluster key 113, 115, 165, 166 
requirements for 167 
Clusters 122, 152 

choosing logical block size 168 
creating 167 
dropping 170 

identifying good tables for 165 

purpose of 165 

space definitions for 115, 168 
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using alternate partitions 168 
CLUSTERS parameter 30 
COL data dictionary view 93 
Cold start 20 

COLIDX data dictionary view 93 
Columns 

attributes of 102 
data 105 
ID 105,118 
length 103, 118 
overhead 105 
Columns cache 9, 30 
COLUMNS data dictionary view 93 
COLUMNS parameter 30 
Command driven products 3 
Comments 

audit trail 203 

COMMIT WORK statement 132 
Commits 29, 64 
automatic 133 
Committing work 131 
Compressed indexes 113, 156, 175 
average entry size 158 
Compressing data 107 
Concatenated indexes 154, 180 
uses of 155 

Concurrent transactions 8, 10, 33, 36, 136, 145 
locks for 143 

CONNECT database privilege 185, 186, 194 
Connects 

auditing 197 
Consistency 143 
CONSOLE parameter 30 
Context area 30, 170 
Context size 

primary extent 170 
CONTEXTINCR parameter 30, 170 
CONTEXT SIZE parameter 30, 170 
Contiguous blocks 112 
Control blocks (DCB) lock 138 
CREATE INDEX statement 177 
CREATE PARTITION statement 99 
CREATE TABLE 108 
CREINIT.COM (VMS file) 29, 32 
CRT files 71,87 
CRT screen 83 
CRT table 74 


CRT tables 
access to 74 
creating 74 
CRT utility 5,71 
running 83, 87 
tables required by 74 
CRT.ERM file 83 
CRTPRODUCTS table 74, 80, 81 
CRT TYPE table 74, 80 
CRTBOX table 74, 78 
CRTINS file 88 
CRTINS.SQL file 74 
CTL locks 51 
Cursor (terminal display) 
cursor coordinates 75, 86 
Cursor, terminal display 73 
Cursors 31, 35 

locks on open 143 
maximum per user 32 
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Data 118 

querying consistent 136 
Data blocks 105, 108 
format of clustered 166 
listing 127 
overhead for 103, 106 
rows per 127 
size of 106 
start address 104 
Data buffers 9, 29 
Data compression 107 
Data control language (DCL) 4 
Data definition language (DDL) 4 
Data dictionary 8, 10, 14, 30, 99, 104, 186 
accessing 93 
creation of 91 
locks on 141 
table definitions 209 
tables of 15,93 
updating 95 
views of 15, 93 
Data dictionary block 105 
Data extents 
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locks while acquiring 141 
minimum INITIAL 104 
Data integrity 13 

Data manipulation language (DML) 4 
Data schema 151 
Data segment 

maximum size 109 
Data, row 103 

Database administrator (DBA) 13 
creating new ones 14, 95 
limiting ORACLE logons to 20, 23 
responsibilities 13 
SYS versus SYSTEM 15 
Database backup 59 
Database buffers 22 
Database files 8, 97, 98, 138 
adding 99 
block size of 29 
creating with CCF 100 
during warm start 21 
maximum number of 31,98 
name of 9, 99 
naming 100 
primary 31 
size of 100 

when to add a new 102 
writing to 11 
Database links 

maximum number of 32 
DATABASE parameter 31, 98, 99 
Database privileges 5 
DATA PAGES parameter 109, 111 
Datatypes 103 
ORACLE 118 

SQL/DS supported by ORACLE 123 
DATE datatype 121 
Dates 

setting ORACLE'S internal 31 
storing 121 

DBA (database privilege) 185, 187 

DBA option (IOR) 20 

DBA privileges 13, 16 

DBLINKS data dictionary view 93 

DCL statements 4 

DDL commits 56 

DDL locks 137,142 


acquiring 141 
releasing 141 
DDL rollbacks 56 
DDL statements 4, 132, 141, 143 
commits 53 
rollbacks 53 
Deadlocks 53, 56 
avoiding 145, 149 
detection 138 
DEBUG option (AIJ) 64 
DECIMAL datatype 124 
Decimal places 121 
DEFAULT table 196 
Default terminal 73 
DEFAULT.CRT file 73,87 
DELETE statements 4 
Deleting data 107 

DEPENDENCIES data dictionary view 
Detached processes 10, 21 
at IOR CLEAR 23 
disabling 33 
dumps created by 31 
starting 21 

DETACHED_DUMPS parameter 31 
Dictionary cache (DCA) lock 138 
Dictionary definition locks 141, 142 
exclusive 142 
shared 142 

Dictionary operation lock 141 
Dictionary operations 143 
Dictionary/Parse locks 137 
DML commits 56 
DML locks 137,143 
DML operations 195, 196 
DML rollbacks 56 
DML statements 4, 59, 105, 136, 145 
commits 53 
locks for 142 

read consistency during 136 
rollbacks 53 
Driver table 174 
Dropping clusters 107 
Dropping database users 185 
Dropping tables 107 
Dropping users 189 
DTAB data dictionary view 93 
DUMP function 118 
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Easy*SQL product 6 
EBCDIC data 73, 123 
Enqueues 56 
Enqueues (ENQ) lock 138 
ENQUEUED parameter 31 
Enrolling users 
syntax for 185 
Enterable fields 76 
ENTRYID 203 
ESC table 74,80,81 
Escape sequences 78, 81 
EXCLUSIVE mode locking 137, 144 
Executable statements 131 
Exponents 119 
Export utility 5 
Extent block 104, 105 
Extents 102, 107, 117 
context area 170 
initial 101 

reaching maximum 117 
requirements for 101 
EXTENTS data dictionary view 93 


F 

Failure, hardware 9, 11 
FILES parameter 31 
First pass (AIJ) 65 
Fixed data (in SGA) 22, 39 
FIXED DATE parameter 31 
FLOAT datatype 124 
Fragmented database 101 
Framing (FRM) lock 138 
Free space 101, 108 
queries to see 101 
Freeing blocks for reuse 107 
Full database import/export 23, 34 
Full table scans 11, 158 
Function codes 81 
Functions (ORACLE) 122 
FUNCTIONS table 74, 80, 81 
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GOTO LC table 74, 75, 82, 86 
GRANT statements 185, 195 
GRAPHIC datatype 124 
Graphics characters 73, 77, 78, 123 
Graphics mode 79 
GROUP BY 177 
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HAVING clauses 

compared to WHERE 178 
Head block (ODS) 47, 135 
Tail block (ODS) 135 
Header block 103, 107 
Headers, block 104 
HELP screen 76 
High block 47 
Highlighting 71 
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I/O activity 43 
I/O display (ODS) 49 
IAD 76 

IDENTIFIED BY clause 186 
IDX data dictionary view 93 
Import utility 5 
INCREMENT parameter 109 
Incremental extents 106 
Index blocks 106, 108 
start address 105 
Index data 108 
Index extents 

calculating 113 
initial 105 

locks while acquiring 141 
minimum INITIAL index 104 
Index segment 
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maximum size 109 
Indexes 98, 102, 105, 152, 158 
B*-tree 163 

checking consistency 163 
compressed 156 
concatenated 154 
internal structure 163 
locks during creation of 142 
maximum size 154 
noncompressed 156 
of multiple columns 154 
syntax for creating 153 
versus keys 152 

INDEXES data dictionary view 93 
Indexing algorithm 
advantages of 164 
INDE>XPAGES parameter 109, 111 
INIT option (IOR) 20 

INIT.ORA file 9, 19, 24, 25, 39, 60, 61, 98, 99, 
100, 194, 203 

distributed versus default values 25 
using a new 37 
using other names 24 
INIT.ORA parameters 

operating system dependent 27 
Initial extents 109, 112 
INITIALIZE option (AIJ) 64 
Initializing the database 9, 19, 20, 21, 60, 94 
cautions about 21 
SQL parameter in INIT.ORA 35 
USER INIT parameter in INIT.ORA 37 
when to 21 
INSE3RT statements 4 
Insertion, data 106 
INSTANCENAME 32 
Instances (ORACLE) 

before image file range 29 
INSTANCES parameter 31 
Instances, ORACLE 

before image file range 29 
maximum number of 32 
name of 32 
starting 20 

INTEGER datatype 124 
Integrity, data 136 
Interactive products 3 
Internal locks 137 


IOR parameters, See INIT.ORA file 
IOR utility 5, 9, 19 
access to 19 
errors received during 38 
syntax 19 


J 

Joins 165, 174 

driving table for 178 
optimizing 178 
Journal block number 65 
Journal files 59, 66 
applying 63 
dynamic creation 62 
naming 62 
nearly full warning 63 
refreshing 64 
writing to 61 

Journal sequence number 60, 64, 65 
updating 66 
Julian dates 121 


K 

Kernel 5 

Key functions (terminal) 71 
Keys 152 
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LANGUAGE parameter 32 
LIST option (IOR) 20 
listing current 20 
Loading data 6, 154 
LOCK TABLE statement 
syntax 137 
lacking 

general rules 148 
Locks 31,43,136 
acquiring 137 
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definition of 136 
lists 9 
releasing 137 
types of 137 
JLocks display (ODS) 50 
Logging off of ORACLE 132 
Logging on to ORACLE 191 
Logical assignments 100 
Logical block size 
determining 168 
overhead 104 
Logical blocks 
overhead 104 
shown in ROWID 125 
Logical reads 53, 55 
Logical units of work 131 
Logical writes 53, 55 
LOGIN.SQL file 191 
LONG datatype 106 
maximum length 122 
restrictions on 122 
LONG RAW datatype 123 
LONG VARC1IAR datatype 124 
LONG VARGRAPH1C datatype 124 
Low block 47 
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Maintenance release (ORACLE) 7 
Maintenance, performing 19, 23 
MAXEXTENTS parameter 109, 112 
limits for 110 

MAXIMUM NUMBER OF EXTENTS EX¬ 
CEEDED 117 
Message line 75, 76 
Monitoring ORACLE use vii, 43 
Multi-user systems 10, 22 
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Names of database objects 91 
NO ACTIVE TRANSACTIONS FOUND mes¬ 
sage 23 

NOAPPLY option (AIJ) 64 
NOAUDIT statement 196, 197 
NOCOMPRESS parameter 157 
NOCONEIRM option (IOR) 20 
Noncomprcsscd indexes 113, 156, 175 
average entry size 158 
Nonshared systems 10 
NOT NULL 

using indexes for 161 
NOWAIT locking option 144 
NULL data 105, 107, 112, 113, 118 
NULL values 
in indexes 161 
NUMBER datatype 119 
negative 119 
positive 119 

representing infinities 120 
representing zero 120 
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Object code (ORACLE) 8 
ODL utility 6 
ODS.LOG file 45 
Online help 99 
OOPEN call 170 
Open transactions 65 
OPEN CURSORS parameter 32 
OPEN LINKS parameter 32 
OPS$ logon ids 188 
ORACLE blocks 106 
ORACLE clusters 20, 47 
ORACLE Display System (ODS) 5, 43, 135 
display cycle 44 
exiting 44 
output file for 43 
ORACLE products 3 
ORDER BY 177 
OSQL3 call 141 
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OUT OP SPACE IN PARTITION 
message 101 

Outstanding transactions 23, 63, 65 
at warm start 21 
Overhead 

column 105 

per clustered block 166 

row 105 


P 

Parameters, INIT.ORA 9, 19, 20, 24 
listing default 39 
listing distributed 39 
space required by 41 
types of 25 
using new 37 
Parsing 142 

Partitions 31, 97, 98, 110, 168 
adding 99 
adding new 97 
altering 187 
clusters and 168 
IDs 101, 125 
naming new 97 
running out of space in 100 
specifying at table creation 110 
tables stored in 108 
using alternate 116 

PARTITIONS data dictionary view 93 
Password, database 186, 188 
Passwords, database 185 
changing 189 

Passwords, operating system 185 
Pattern matching 175 
PCTFREE parameter 106, 107, 110, 112 
clusters 115 
Performance 25 
PFILE option (AIJ) 65 
PFILE option (IOR) 20 
Physical blocks 
overhead 104 
shown in ROWID 125 
Physical reads 53, 55 
Physical writes 53, 56 


Precision, data 119, 120 
Precompilers 7 
Privileges, database 91 
revoking 189 

PRIVSYN data dictionary view 93 
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Pro*C product 7 
Pro*COBOL product 7 
Pro*FORTRAN product 7 
Pro*Pascal product 7 
Pro*PL/I product 7 
Process display (ODS) 51 
Processes 9 

dump files for user 37 
IDs 52 

terminating abnormally 11 
Processes (PCB) lock 138 
PROCESSES parameter 25, 33, 36 
Processes, user 43 
Product codes 81 
PUBLIC synonyms 187, 190 
listing 190 

using same names as for 190 
PUBLIC user 190 
PUBSYN data dictionary view 93 


Q 

Queries 4, 11 


R 

RAW datatype 123 
RDBMS, the ORACLE 5 
Read consistency 134, 136 
before image file and 135 
READ BLKS REQ parameter 33 
READ BLKS TOT parameter 33 
READ REQUESTS parameter 33 
Recovery 9, 59 
Recursive cursors 56 
Redundant data 13 
Regaining space 108 
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Relational theory 151 
Relative block address (RBA) 54 
Release media 8 
Reserved words 205 

RESOURCE database privilege 117, 185, 187, 
194 

Resources, requesting 31 
Restoring data 5 
Retrieving data 4 
Reverse video 71, 73, 78 
Revision level (ORACLE) 7 
REVOKE statements 195 
syntax 189 

ROLLBACK WORK statement 133 
Rollbacks 

automatic 134 

Rolling back transactions 11, 21, 29, 64, 131 
Rolling forward (AIJ) 59, 60, 63 
description of passes 1 and 2 65 
inhibiting pass 2 64 
Row length 103, 105, 113 
Row sequence number 104, 105, 113, 125 
Row-level locks 126, 143, 145, 146, 148 
releasing 144 
when to use 147 
ROWID 105, 124, 175 
cautions about 126 
components of 125 
uses of 126 

ROWNUM keyword 105 
Rows 

addresses 124 
physical location 126 
uniquely identifying 152 
ROWS parameter 153 
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Scale, numeric data 119, 120 
Screen painter 76 
Screen protection 77 
Scrolling (display terminal) 73, 76 
Second pass (AIJ) 64, 65 
Security 193 
Segments 102 


SELECT ... EOR UPDATE 146 
SELECT DISTINCT 177 
Semigraphic characters 73 
Session, user 

ENTRYID 203 
SESSIONID 203 
USERENV function 202 
Sessions (auditing user) 195 
SGI utility 5, 39 

DETAIL option 40, 41 
LIST option 40 
sample output 39, 42 
syntax for 39 

SHARE mode locking 137, 144 
SHARE UPDATE locking 145, 146 
SHARED option (IOR) 20, 24 
SHARED option of IOR 100 
Shared partition system 

adding partitions to 100 
Shared systems 10 
SHUT option (IOR) 20 
Shutting down ORACLE 9, 19, 20 
interrupting when users are active 23 
shutting versus clearing 22 
Sign bit 119 
Single-user systems 10 
enabling 33 

SINGLE PROCESS parameter 33 
SINGLE USER parameter 10 
SMALLINT datatype 124 
Sort/merge routine 177 
SORT AREA SZ parameter 33 
SORT FINAL RA parameter 34 
SORT MERGERA parameter 34 
SORT POOL SZ parameter 34 
SORT_READ_EAC parameter 34 
SORT_SPCMAP_SZ parameter 34 
Sorting 34 

Space definitions 102, 107, 108 
altering 116 
clusters and 168 
creating 111 
default 109, 115 
dropping 117 
for temporary tables 129 
general recommendations 111 
invoking 115 
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listing existing 110 
names of 111 
syntax for 111 
table creation and 108 
SPACES data dictionary view 93 
Split screens 73 
SQL data language 4 

types of statements in 5 
SQL parameter 35 
SQL.ORA file 35 
SQL*Calc 72 
SQL*Calc product 6 
SQL + Forms 72 
locking in 147 
SQL + Forms product 6 
SQL*Graph product 6 
SQL*Menu 72 
SQL*Menu product 6 
SQL*Net 123 

data conversion 123 
SQL* Net product 6 
SQL + Plus product 6 
SQL* Report 6 
Start address 

data block 104 
index block 105 
Starting database 129 
Starting ORACLE 9, 19, 20, 21, 194 
for DBA only 20 
for ORACLE instances 20 
logging in while 22 
outstanding transactions during 23 
with new INIT.ORA file 37 
Status line 75 

Stopping ORACLE, See Shutting down 
ORACLE 

STORAGE data dictionary view 93 
SUBSTR function 126 
Summary display (ODS) 53 
Synchronous devices 72, 80 
Synonyms 
cached 36 
listing PUBLIC 190 
SYNONYMS data dictionary view 93 
SYS user (DBA) 13, 14, 187 
password for 14 
tables belonging to 94 


using tables belonging to 15 
SYSCATALOG data dictionary view 93 
SYSCOLAUTH data dictionary view 93 
SYSCOLUMNS data dictionary view 93 
SYSDATE 31 

SYSDBLINKS data dictionary view 93 
SYSEXTENTS data dictionary view 93 
SYS INDEXES data dictionary view 93 
SYSPROGS data dictionary view 93 
SYSSORT parameter 153 
SYSSTORAGE data dictionary view 93 
SYSTABALLOC data dictionary view 93 
SYSTABAUDIT table 201 
SYSTABAUTH data dictionary view 93 
System failure 59, 131, 134 
System global area (SGA) 9, 11, 19, 24, 134, 138 
size of 9, 26 
testing size of 39 
System id 32 

SYSTEM partition 31, 97, 98, 111, 115, 129 
description of 98 
SYSTEM user 14 
SYSTEM user (DBA) 13, 187 
adding new objects to 95 
clusters in 94 
CRT tables owned by 74 
password for 15 
views belonging to 94 
SYSTEM AUDIT table 202 
SYSUSERAUTH data dictionary view 93 
SYSUSERLIST data dictionary view 93 
SYSVIEWS data dictionary view 93 
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TAB data dictionary view 93 
TABSRBA 104, 105 
TABALLOC data dictionary view 93 
Table access (TAC) lock 138 
Table creation 105 
Table definition locks 141 
exclusive 143 
shared 143 

Table definitions cached 36 
Table display (ODS) 54 
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releasing 143 
shared 144 
Table names 102 
cached 36 

Table/Row locks 137, 143 
TABLEACCESSES parameter 35, 36 
TABLE HANDLES parameter 35, 36 
TA BLE I IS 1 I BKTS parameter 36 
TABLENAMES parameter 36 
Tables 35 

creating 101, 110 
data segment 102 
index segment 102 
large 98 

logical format for non-clustered 103 
space for data 108 
specifying partitions 110 
Tables cache 9, 54 
TABLES parameter 25, 36, 54 
Tables, database 98, 102 
TABQUOTAS data dictionary view 93 
Tail block (ODS) 47 
TEMPTABIJES parameter 36, 129 
Temporary tables 36,99, 102, 110, 138 
dropping 22 
space definition for 129 
when created 128 
when required 128 
Temporary tables (TMP) lock 138 
TEMPTABLE space definition 110, 129 
Terminal codes 81 
Terminal definitions 71 
adding 83 
custom 71 
default 71, 88 
modifying 87 
Terminal id 52, 203 
Terminals 

number of columns on 75 
number of lines on 75 
resetting 76 
Text formatting 6 
Times 

default 121 
how to enter 121 


storing 121 
Timestamps 103 
T0_CHAR function \7l 
TO DATE function 121 
Trace files 37 
Trailing blanks 118 
Transactions 8, 131, 138 
blocks used by active 47 
IDs 65 

maximum concurrent 36 
numbers 138 

Transactions (ERT) lock 138 
TRANSACTIONS parameter 36 
Triggers 148 
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Underlining 71, 73 
Uniqueness 

guaranteeing in data 152 
Units of work 131 
ending 131 
locks on active 138 
starting 131 

Unrecoverable recursion errors. 99 

UNTIL option (AIJ) 65 

UPDATE statements 4 

Updates, data 107 

Upgrading ORACLE 21 

Usage (database) 95 

Used blocks 47 

User display (ODS) 55 

User ids (ORACLE) 91 

User names cached 37 

USER DUMPS parameter 37 

USERENV function 202 

USERENV function. 32 

USER I NIT parameter 37 

Username, database 185, 186, 188 

Username, operating system 185 

USERS ACTIVE message 23 

Users cache 9 

USERS parameter 37 

USERS STILL ACTIVE message 23 

Users, current 138 
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VALIDATE INDEX command 163 
VARCIIAR datatype 124 
VARGRAPHIC datatype 124 
Variable data (in SGA) 22, 39 
Variable parameters 26 
Version number (ORACLE) 7 
View names cached 36 
Views 

auditing of 196 

based on logon information 203 
VIEWS data dictionary view 93 
VIEWXREF data dictionary view 93 


Virtual machines 10 
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Waiting for resources 142 
WARM option (IOR) 20 
Warm starting ORACLE 20, 21 
WHERE clause 174 
optimizing 174 
WHERE clauses 

compared to HAVING 178 
WINDOW (terminal attribute) 76 
WORD_WRAP option 123 
Worksize 30 
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